ietf
[Top] [All Lists]

Re: Order of CNAME and A in Authoritative Reply.

2015-08-11 12:58:52
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