[dns-operations] How DNS work

[Jim Reid]

> On 9 Nov 2020, at 04:15, Hoan Vu <vuhoan3108 at gmail.com> wrote:
> 
> We really wanna know "what is round robin of DNS" and the nature of the rule to choose the DNS Root of Resolver, what factor, algorithm, .... that decide the choice of DNS Root.

Why? Nobody needs to care about this - apart from the people who write DNS resolvers.

If you *really* want to know, consult the source code. There are quite a few open source DNS resolver implementations: BIND, unbound, Knot resolver, PowerDNS Recursor, etc.

For everyone else, all they need to know is their resolving servers generally query the authoritive server that answers quickest: ie the one that has the shortest round-trip time (RTT) for the query and response. This isn’t necessarily the authoritative server that’s physically closest. Factors beyond your control like network topology, hop count, bandwidth, routing/peering policies, server/router load, packet loss, etc. can sometimes mean an authoritative server 100km away is quicker to respond than one that’s only 100m away.

Resolving servers continuously monitor the RTT to all the authoritative servers for some domain and adjust where they send their queries based on what is happening in the network - for instance when a link fails or an unresponsive server comes back on-line.

“round robin in the DNS" is something very different from this. It’s mostly found in (stupid IMO) resolver configurations that use forwarding. In these, the server is given a list of servers and just forwards its queries to those servers. It mindlessly tries the first one in the list, then the next and so on. When it comes to the end of the list, the forwarder goes back to the start and cycles through the list again: hence round-robin. These forwarding configurations generally don’t care about RTTs and will usually forward queries to a server on this list even when they they know that server is dead.

> Suppose that we have one Root Secondary Node of Anycast in our country (example DNS Root K), and we want to direct query of the DNS Cache to the that DNS Root, how can we interfere the resolve process to do that (unless otherwise configure only DNS Root K)

Don’t do that. Unless you’re forced to by law (ie “all DNS queries must remain inside our borders” or some stupid rule like that). Just let the resolving server decide for itself which servers are quickest to answer queries. It will do a far better job of that than you can. And also adapt in real time to outages, changes in network topology and so on. If you force a resolving server to always query a specific authoritative name server, that creates an avoidable and unnecessary single point of failure. It also complicates the management and configuration of the local server and day-to-day DNS operations.

If your DNS queries are not going to the nearest anycast node (for some definition of nearest) and that’s a concern, fix the underlying issue. Which is routing, not DNS. 

I also don’t understand why you seem to be so concerned about optimising queries to a root server. A well behaved resolving server will only send a handful of queries (if that) to the root every day - ie whenever it needs to lookup a TLD that hasn’t been cached.