Hi Joe,
Paraphrasing with more detail, a query with RD=0, QTYPE=A and some
QNAME is sent to an authoritative server. The corresponding owner name
is a CNAME, with some target, and the target owner name has an A RRSet
associated with it. The authoritative server responds with both the
CNAME and the A RRSet in the ANSWER section, if it is able to include
both elements authoritatively (i.e. it's authoritative for the target
owner name).
Agreed, and thanks for the precision.
The question is whether there is a specified order for the different
RRSets present in the ANSWER section of the response, and the answer
seems to be no.
AFAIK. An additional quote I forgot before that has come up when
discussing this off list:
https://tools.ietf.org/html/rfc1034#section-3.6
A domain name identifies a node. Each node has a set of resource
information, which may be empty. The set of resource information
associated with a particular name is composed of separate resource
records (RRs). The order of RRs in a set is not significant, and
need not be preserved by name servers, resolvers, or other parts of
the DNS.
(Note, this RFC pre-dates RRsets.) Although it say "order is not
significant" that's only for those associated with a particular name,
i.e. all the A RRs for foo.com, as I read it.
BIND/named seems to have done the obvious from early on, appending
the CNAME to the reply, and then appending the A. Clients have come
to depend on this behaviour, assuming on seeing the CNAME that they
can switch horses to the CNAME's value and continue processing the
packet from that point.
What clients are you talking about, here?
Well, ping(1), say, using glibc's resolver.
DNS servers that don't follow this unwritten convention thus break
some of the many and varied clients that already exist.
Can you support this with data?
There's the 50%-round-robin-ping failure I mentioned before. Examining
other stub resolvers showed glibc isn't alone in its assumption.
An ad hoc survey of clients...
4.3BSD's named built the reply in the obvious (CNAME, A) order,
and its client expected the same.
I'm not sure the behaviour of obsolete versions of BIND is especially
relevant, although the history is interesting.
Well, I was wondering how far back parsers of replies could have been
lead to believe a certain order was guaranteed.
glibc and dietlibc both expect (CNAME, A).
Neither of those are generally clients of authoritative servers, I
think.
uclibc stops on seeing the CNAME, sending another request! But it
means it happens to `work' with (A, CNAME).
This isn't a client of an authoritative server either.
Finally Go came along in 2008, probably influenced by Plan 9's
implementation, though I haven't checked that. It alters what it
wants on seeing the CNAME, and restarts parsing the whole packet.
Go the programming language? I'm confused as to how that's a client of
an authoritative server, either.
Go implements its own resolver rather than use the local libc's, e.g.
glibc's. All of them are stub resolvers, yes, but if asked to look up
foo.bar.local and /etc/resolv.conf has only the authoritative bar.local
server in it then they get an authoritative response without a
third-party recursive resolver being involved.
Is it possible that you're actually talking about the behaviour of
recursive servers when returning responses to stub resolvers?
No, not in this case. Let's say I was, if the MITM recursive resolver
knew nothing, queried the authority and got (A, CNAME) back in the one
reply, is it defined that it's responsible for passing that back to the
stub in a particular order, e.g. (CNAME, A)?
Cheers, Ralph.