Hi Viktor, On 11 Aug 2015, at 11:11, Viktor Dukhovni wrote: > On Tue, Aug 11, 2015 at 03:56:03PM +0100, Ralph Corderoy wrote: > >>> Which clients that are not recursive resolvers talk directly to >>> authoritative nameservers (not counting "nslookup", "dig", ...)? >> >> Those, like ping, where a foo.local is provided by a local, >> authoritative, nameserver. DNS is increasing being used on a local >> level, e.g. as a distributed key/value lookup. That's one reason why >> new servers are coming along and meeting old clients. > > The ping program talks to whichever recursive resolver is specificed > in /etc/resolv.conf. More detail is useful, here. The ping program uses a local API to translate a name into an address. In the case where that translation requires use of the DNS, a stub resolver sends a query to a recursive resolver. So probably the stub resolver that we're talking about here is one of those included in one of those libcs mentioned previously. > Perhaps in the case of ".local" and mDNS, > there are platform-specific variations in how such names are > resolved. In the case where that translation requires use of some other protocol like bonjour or tor, different mechanisms are used. >>> However, it is not clear why the order of records in a non-recursive >>> response needs to be constrained in any way. Surely, recursive >>> resolvers can reorder the records as necessary? >> >> I have a lack of DNS Fu. If the recursive resolver looking up (A? >> foo.local) talked to the authoratitive server that answered (A >> bar.local=1, CNAME foo.local=bar.local) then, assuming it understood >> that completely answered the question, might it not simply copy the >> answer back to the client without re-ordering? > > Recursive resolvers construct answers from their caches, and may > need to query multiple nameservers ... recursive servers, authoritative servers, or both... > to obtain the information needed > to provide the answer returned to the client. They generally don't > just proxy response packets from upstream servers. They are specified not to, in fact, in the sense that they have requirements such as RD/AD/CD processing, managing TTLs, etc. Joe
Attachment:
signature.asc
Description: OpenPGP digital signature