[Afpif] peer config to use root DNS anycast instances at an IXP

Patrick Okui pokui at psg.com
Sat Jan 2 04:56:38 UTC 2021

[removing cross-post to private af-ix list]

On 1 Jan 2021, at 15:11 EAT, Dr P Nyirenda wrote:

> Happy new year 2021, am previledged to send you the first message on 
> this AF-IX mailing
> list :-), hope we have good discussions in 2021

Happy New Year.

> How should an ISP peering at the MIX configure its DNS to use the D 
> and E root DNS
> instances at the MIX for it and its clients?

Long story short, they really shouldn’t (and it’s not really 
configurable). Ideally caching name servers know that different root 
instances will have different latencies and figure out the “best 
ones” during startup. IIRC they use the term “priming” the root 
hints. They then keep track of performance over time but the details 
depend on the DNS server software being used.

Even if the members edited their caching servers root hints the caching 
name server will only use those servers to refresh their internal list 
of all roots during startup and thereafter ignore the hints.

Google turned up [this old 
from 2012 that investigated how the various implementations behaved. 
Also [this paper on 
wrt to DNS pops up. I’m sure more search engine time can bring up more 

As an IX operator the more roots you can get in the better the 
performance will generally be across various implementations. Also, 
various root operators also carry records for different TLDs.

> For example if I do a dig +trace like the one copied here below, you 
> will see that my dig query
> was answered by c.root-servers.net which is at least 160ms away which 
> is not the nearest
> DNS root server instance at the MIX

dig +trace does not check latency for the root it picks. Instead it 
tries to pick a random root server each time. Run it a couple of times 
to see. A better test would be to either run a caching server (if most 
ISPs use the same one) in debug mode or with extra logging (or packet 
capture of the queries) and see what it picks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.afpif.org/pipermail/afpif/attachments/20210102/892a3932/attachment.htm>

More information about the Afpif mailing list