Hi Ralph,
On 11 Aug 2015, at 10:09, Ralph Corderoy wrote:
If a non-recursive DNS query for an A RR is sent to the authoritative
server for both the queried CNAME and the A RR that's its value, it
does
not seem to be clearly stated in the RFCs that the CNAME answer shall
precede the A answer in the reply.
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).
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.
The further question is whether the order is important.
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?
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?
Not suggesting that you're wrong, but these are interesting and
surprising statements to me, and I'd like to learn more.
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.
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.
Is it possible that you're actually talking about the behaviour of
recursive servers when returning responses to stub resolvers?
Joe