<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">[removing cross-post to private af-ix list]</p>
<p dir="auto">On 1 Jan 2021, at 15:11 EAT, Dr P Nyirenda wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #5855D5; color:#5855D5; margin:0 0 5px; padding-left:5px"><p dir="auto">Happy new year 2021, am previledged to send you the first message on this AF-IX mailing<br>
list :-), hope we have good discussions in 2021</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Happy New Year.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #5855D5; color:#5855D5; margin:0 0 5px; padding-left:5px"><p dir="auto">How should an ISP peering at the MIX configure its DNS to use the D and E root DNS<br>
instances at the MIX for it and its clients?</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">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.</p>
<p dir="auto">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.</p>
<p dir="auto">Google turned up <a href="https://www.dns-oarc.net/files/workshop-201203/OARC-workshop-London-2012-NS-selection.pdf">this old presentation</a> from 2012 that investigated how the various implementations behaved. Also <a href="https://link.springer.com/chapter/10.1007/978-3-540-71617-4_13">this paper on anycast</a> wrt to DNS pops up. I’m sure more search engine time can bring up more resources.</p>
<p dir="auto">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.</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #5855D5; color:#5855D5; margin:0 0 5px; padding-left:5px"><p dir="auto">For example if I do a dig +trace like the one copied here below, you will see that my dig query<br>
was answered by c.root-servers.net which is at least 160ms away which is not the nearest<br>
DNS root server instance at the MIX</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">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.</p>
<p dir="auto">--<br>
patrick</p>
</div>
</div>
</body>
</html>