DNS NS Question

Kevin Darcy kcd at daimlerchrysler.com
Tue Nov 15 23:23:48 UTC 2005

News wrote:

>I have a query on how DNS resolves in regards to name servers (NS) records
> can somebody please explain this to be by way of the following example:
>Ok so given the following setup of a domain:
>example.net.             172791  IN      NS      ns1.example.net.
>example.net.             172791  IN      NS      ns2.example.net.
>example.net.             172791  IN      NS      ns3.example.net.
>If I am trying to resolve host1.example.net for example.
>Does the DNS resolveer work like this.
>Try ns1.example.net if there is no host found then it tries
>ns2.example.net and so on. So it keeps working its way down until
>one of the NS servers says it can Resolve the query?
No, "no host found" implies that one of the nameservers actually gave a 
response to the effect that the query matched no name (or no records, 
which is subtly different) in the DNS database. Once a response is 
received by one of the nameservers, it is taken as definitive, since all 
of those nameservers are expected to have the same data (transient 
replication delays notwithstanding). Failover from one nameserver to 
another only occurs as long as there is no response.

>Or does it simply make a dns type query if it is not found then
>say that is not there Return host not found. So the multiple NS
>records just mean if it can make a tcp connection To the first
>it tries the next one.. This is what I am trying to understand how
>it works?
That's more like how it works, with some minor clarifications:

1) The queries are made using UDP datagrams rather than TCP connections, 
unless the data is too big to fit in a UDP packet.

2) As far as nameserver selection goes, most iterative-resolver 
implementations will pick nameservers based on its prediction(s) -- 
based on prior experience -- of which will respond faster than others. 
So it's not a strict sequential order each time. If there is no data 
with which to make a prediction, e.g. if the iterative-resolver just 
came up and therefore has no relevant records cached, then generally 
it'll proceed in a random order. In fact, there's no guarantee that the 
delegation records (what you show above) will always be given out in the 
same order. Implementations can choose to mix them up if they wish. 
Perhaps what is confusing you is that most registrars ask for 
delegations as "nameserver #1", "nameserver #2", etc. as if there were 
some strict ordering sequence. That's just their way of keeping track of 
delegation records in the registry database; within the DNS protocol 
itself, that ordering doesn't matter.

                                                                 - Kevin

More information about the bind-users mailing list