Subject: Re: [DNSOP] Anycast and DNS questions

From: Antoin Verschuren <[email-masked]>
Date: Tue, 2 Sep 2014 09:28:15 +0200

Op 27-08-14 om 16:04 schreef David Conrad:
> Hi,
>
> On Aug 27, 2014, at 1:11 AM, Guangqing Deng <[email-masked]
<mailto:[email-masked]>> wrote:
>> Here, one interesting question  can be raised is what is the best
localization policy for DNS? Should DNS clients visit the anycast server
with the least network latency (which can be measured by RTT) or minimal
AS hops or minimal router hops? In other words, the question is about
what is the best assessment index for DNS system.
>
> I suspect DNS clients care primarily about getting correct answers as
quickly as possible.  I doubt they care about hops be they AS or router.

Question is: Why do you anycast in the first place.
I think for DNS, primary reason is redundancy and resilience, which is
why spreading capacity is the primary goal.
Reducing latency, or better, not increasing latency by introducing
anycast is it's secondary goal.
For other services, goals may be different.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Sep 2014 10:31:03 +0300

> anycast is it's secondary goal.

For a number of customers of at least one provider I know (my
employer), the reverse is true.  Customers expect 100% uptime from
their DNS as a matter of course, and they don't care about anycast for
that reason.  They care about performance of page loads, and nothing
else.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 2 Sep 2014 09:45:01 +0200

> that reason.  They care about performance of page loads, and nothing

Which is sort of what I was saying.
First goal is to have 100% uptime. Second goal is performance.
Low latency -if- you get an answer is not enough.
You want an answer all the time, and not a fast one 90% of the time and
none 10% of the time.
Ideally you want a fast answer 100% of the time.

- -- 
Antoin Verschuren

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Sep 2014 16:47:07 +0900

> why spreading capacity is the primary goal.

Then, your reason has little to do with anycast.

See, for example, draft-ietf-dnsop-ohta-shared-root-server...

						Masataka Ohta

---

From: "Guangqing Deng" <[email-masked]>
Date: Wed, 3 Sep 2014 12:00:25 +0800

I am interested in the topic of the redundancy and resilience of the DNS system, and are there any specific documents about this topic, such as how to achieve that goal?

Guangqing Deng
CNNIC 
 
From: Antoin Verschuren
Date: 2014-09-02 15:28
To: [email-masked]
Subject: Re: [DNSOP] Anycast and DNS questions

 
- -- 
Antoin Verschuren

 
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Sep 2014 18:20:16 +0900

Guangqing Deng wrote:

> I am interested in the topic of the redundancy and resilience of the
> DNS system, and are there any specific documents about this topic,
> such as how to achieve that goal?

rfc1034 section 4.1.

					Masataka Ohta

---

From: "Guangqing Deng" <[email-masked]>
Date: Wed, 3 Sep 2014 23:42:15 +0800

From RFC1034 section 4.1, it seems that the way used for improving the redundancy and resilience of DNS system is to increase DNS servers. I agree that for the performance of the DNS system, the redundancy and resilience are the first goal and low latency is the second goal. Usually, the first goal mainly depends on the DNS server deployment policy (such as the total number and geographical distribution of DNS severs) and the second goal relates to not only the DNS server deployment policy but also the method used for DNS clients selecting the best DNS server like anycast. In my opinion, to obtain higher resilience as well as lower latency, there may be two phases in deploying DNS servers.  In the first phase, some DNS servers should be deployed at secure sites that have rare natural and man-made disasters for better resilience and then in the second phase the other DNS servers should be deployed at those sites that are near DNS clients as much as possible for lower latency. And anycast may only be one kind of technology, which makes the DNS clients access the nearest DNS server but not the other DNS servers when deployment sites of all DNS servers are fixed.

Guangqing Deng
cnnic 

From: Masataka Ohta
Date: 2014-09-03 17:20
To: dnsop

rfc1034 section 4.1.

Masataka Ohta

---

From: Chris Thompson <[email-masked]>
Date: 03 Sep 2014 17:04:32 +0100

On Sep 3 2014, Guangqing Deng wrote:

>From RFC1034 section 4.1, it seems that the way used for improving the
>redundancy and resilience of DNS system is to increase DNS servers.

It might be better to start from RFC2182 "Selection and Operation of
Secondary DNS Servers", a mere 17 years old rather than 27 (and a lot
more detailed) although it still predates widespread use of anycast
in the DNS context.

Nothing has officially superceded RFC2182 and it remains a Best Common
Practice document (BCP0016).

-- 
Chris Thompson               University of Cambridge Information Services,
Email: [email-masked]    Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715       Cambridge CB3 0RB, United Kingdom.

---

From: David Conrad <[email-masked]>
Date: Wed, 3 Sep 2014 10:01:50 -0700

Hi,

On Sep 3, 2014, at 8:42 AM, Guangqing Deng <[email-masked]> wrote:
> From RFC1034 section 4.1, it seems that the way used for improving the redundancy and resilience of DNS system is to increase DNS servers. I agree that for the performance of the DNS system, the redundancy and resilience are the first goal and low latency is the second goal. Usually, the first goal mainly depends on the DNS server deployment policy (such as the total number and geographical distribution of DNS severs) and the second goal relates to not only the DNS server deployment policy but also the method used for DNS clients selecting the best DNS server like any cast.

Careful here.

Anycast improves redundancy/resiliency for the system as a whole.  As typically deployed, it may not improve redundancy/resiliency for a single client.  For example, if a DNS server instance in an anycast cloud is no longer responding to DNS queries due to a DoS but the routing announcement of that instance is not pulled down, the clients topologically nearest that instance will not see improved redundancy/resiliency — they’ll not see any responses.

Anycast may or may not improve latency — it depends on the routing system. If the “nearest” instance network topologically to a set of clients happens to be on the other planet, latency will not be improved for those clients.

Anycast is a very blunt tool. It can help improve redundancy/resiliency and latency if properly deployed, constantly monitored, and maintained, but it is very important to understand its limitations and implications.

Regards,
-drc

---

From: joel jaeggli <[email-masked]>
Date: Wed, 03 Sep 2014 10:21:29 -0700

On 9/3/14 10:01 AM, David Conrad wrote:
>> From RFC1034 section 4.1, it seems that the way used for improving
>> the redundancy and resilience of DNS system is to increase DNS
>> servers. I agree that for the performance of the DNS system, the
>> redundancy and resilience are the first goal and low latency is the
>> second goal. Usually, the first goal mainly depends on the DNS
>> server deployment policy (such as the total number and geographical
>> distribution of DNS severs) and the second goal relates to not only
>> the DNS server deployment policy but also the method used for DNS
>> clients selecting the best DNS server like any cast.

anycast is not a selection mechanism employed by a client. it is the
network that determines the catchment area served by a given anycast
instance.

> Careful here.
> 
> Anycast improves redundancy/resiliency for the system as a whole.  As
> typically deployed, it may not improve redundancy/resiliency for a
> single client.  For example, if a DNS server instance in an anycast
> cloud is no longer responding to DNS queries due to a DoS but the
> routing announcement of that instance is not pulled down, the clients
> topologically nearest that instance will not see improved
> redundancy/resiliency — they’ll not see any responses.
> 
> Anycast may or may not improve latency — it depends on the routing
> system. If the “nearest” instance network topologically to a set of
> clients happens to be on the other planet, latency will not be
> improved for those clients.
> 
> Anycast is a very blunt tool. It can help improve
> redundancy/resiliency and latency if properly deployed, constantly
> monitored, and maintained, but it is very important to understand its
> limitations and implications.
> 
> Regards, -drc
> 
> 
> 
> 
> _______________________________________________ DNSOP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Joe Abley <[email-masked]>
Date: Wed, 3 Sep 2014 16:32:47 -0400

> network that determines the catchment area served by a given anycast

RFC4786 may be a useful reference.

(and I remember when that document was progressing through the IESG there was confusion over the word "catchment"; we inserted a definition to make the use of that word clearer, pasted here since Joel used it too.)

  Catchment:  in physical geography, an area drained by a river, also
      known as a drainage basin.  By analogy, as used in this document,
      the topological region of a network within which packets directed
      at an Anycast Address are routed to one particular node.

Joe

---

From: George Michaelson <[email-masked]>
Date: Thu, 4 Sep 2014 09:27:33 +1000

DNSSEC signing problems get worse with more NS, if the signatures go bad.
Even with the remediation Mark Andrews put in later bind, there is an
increase in traffic at the authority points and in the system as a whole.

So "more is better" is not necessarily true.

Also, AAAA ns and A NS are morally considered 'different' NS by the system
because they do not present as the 'same' NS to the logic of 'where shall I
ask next' (I don't understand why: the NS label should be the same.
however, we observe that we see NS traffic on the V6 and V4 at the same and
also sequentially. Therefore, I beleive this)

So, having the SAME NS in as both V6 and V4 (is that V10?) does not help
you: it can, in bad DNSSEC, actually hinder you.

Oh, 464XLAT since it has to write non-authoritative changes into AAAA/A
bindings, breaks DNSSEC. so if you are behind 464XLAT, and DNSSEC signed,
more NS is not neccessarily helping you...

On Thu, Sep 4, 2014 at 3:01 AM, David Conrad <[email-masked]> wrote:

> redundancy and resilience of DNS system is to increase DNS servers. I agree
> that for the performance of the DNS system, the redundancy and resilience
> are the first goal and low latency is the second goal. Usually, the first
> goal mainly depends on the DNS server deployment policy (such as the total
> number and geographical distribution of DNS severs) and the second goal
> relates to not only the DNS server deployment policy but also the method
> used for DNS clients selecting the best DNS server like any cast.
>
> Careful here.
>
> typically deployed, it may not improve redundancy/resiliency for a single
> client.  For example, if a DNS server instance in an anycast cloud is no
> longer responding to DNS queries due to a DoS but the routing announcement
> of that instance is not pulled down, the clients topologically nearest that
> instance will not see improved redundancy/resiliency — they’ll not see any
> responses.
>
> Anycast may or may not improve latency — it depends on the routing system.
> If the “nearest” instance network topologically to a set of clients happens
> to be on the other planet, latency will not be improved for those clients.
>
> Anycast is a very blunt tool. It can help improve redundancy/resiliency
> and latency if properly deployed, constantly monitored, and maintained, but
> it is very important to understand its limitations and implications.
>
> Regards,
> -drc
>
>
>