To understand the DNS, I tried to write a simple resolver without a cache that could perform recursive queries, starting with root servers. There was a problem: if the server does not have the requested data, then it returns to us in the Authority-section NS-records with the names of those servers that are "closer to the answer", but it is not obliged to return the A-records in the Additional-section, respectively. NS records in Authority sections . He just may not know the addresses of these servers - is not required. They may not be in his zone. The exception is glue records.

Thus, it turns out: we have a name, the address of which we should receive. We are accessing one of the root servers (we take its address from the config). It returns to us the names of servers that are “closer to the answer” (probably, those whose zone includes the Top-Level-Domain). But he does not inform us of their addresses. They will let you know, but at the next iteration, one of these servers will tell us the name of the server "closer to the answer", but not its address. So we will already have 2 names in our hands, the addresses of which need to be obtained, and we will not receive the address of the first one without knowing the address of the second one. We will try to get the address of the 2nd, we get another name. Recursion, damn it! As if everything was simpler, if the NS records had an address, not a name. But no, in theory, by any name using the DNS system, we can get a match. address, but in practice it complicates the process.

Question: why in NS-records contains the name and not the address? Do DNS server addresses change so often that it’s difficult to update a zone file? The convenience here is a small plus compared with the complexity of the whole scheme. Why is this recursion (which I have described) generally finite?

PS: I know that having experimented, manually executing consecutive requests, m. I would understand what's the matter, but my hands do not reach. Maybe someone else will be useful my comment / comment on the DNS.

    1 answer 1

    why NS records contain a name, not an address?

    because that is exactly how rfc1035 is .

    this gives a certain flexibility and backward compatibility: for example, even within the framework of the same arpanet , a completely different address scheme was added not so long ago, and a resource record had an addition in the form of aaaa resource record . and in fact (in principle) the light did not come together with an arpanet , and the addition of new addressing schemes would easily fit into the current implementation of the protocol.

    addition about scalability

    the same name can be “serviced” by an arbitrary number of physical devices:

    $ dig -ta ya.ru ;ya.ru. IN A ya.ru. 5833 IN A 93.158.134.3 ya.ru. 5833 IN A 213.180.193.3 ya.ru. 5833 IN A 213.180.204.3

    add-on pro extensibility

    the same name can be “serviced” by physical devices accessible from different networks:

     $ dig -t aaaa ya.ru ;ya.ru. IN AAAA ya.ru. 22 IN AAAA 2a02:6b8::3

    addition about compatibility

    when in the future it becomes necessary to address physical devices on some completely new network, the protocol will not need to change anything . it will be enough just to add another record type:

     $ dig -t xyz ya.ru ...
    • because that's exactly what rfc1035 says - thanks, laughed. But seriously: no problem, even if the NS record format (RDATA) would be: <addressing type> <address>. - cucaracha
    • @cucaracha, let then - not the slightest problem! in your own network, you can opt out of both compatibility and scalability. - aleksandr barakin