[Afpif] peer config to use root DNS anycast instances at an IXP
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...
More information about the Afpif