Re: [DNSOP] [Ext] order of records in DNAME responses

[Edward Lewis <[e-mail]>]

On 2/23/17, 18:24, "DNSOP on behalf of Evan Hunt" <[e-mail] on behalf of [e-mail]> wrote:

>I'd like to start a discussion of that now.  Does anyone have a problem
>with the idea of clarifying the protocol here, saying that the order of
>records in the answer section of a chaining response is significant, and in
>particular, that a DNAME MUST precede the corresponding synthesized CNAME?

Protocol Specification Wars
Episode MMCMLXVII

A long, long time ago in a galaxy far, far away...

>From a time when I spent a lot of attention on the section titled "The Algorithm" in "Domain names - concepts and facilities", that is section 4.3.2 of RFC 1034, I was reminded by one of the originators of the protocol that the RFCs were intended to capture the spirit of the protocol, that passages such as that in 4.3.2 weren't crafted even to the point of being pseudo-code.  There were merely spirit guides.  Since then I've thought of the RFCs as guides to how to enable interoperability between implementations rather than standards documents with testable criteria for compliance.

(As an engineer and one-time coder, I wanted spec docs, tried to write that way.  I'm sympathetic to that desire, but, the IETF was founded to promote interoperability not solve user stories.)

I'm just throwing that out as a point of history, unsupported by any reference because it was either in person or in private email.  To me it explains how the, at least, early documents were prepared, with "earlier" meaning lower in RFC series number.

The reason I point this out is that the order of records in a section has been famously undefined, with the convention of supporting round robin (an undocumented feature of the protocol) hanging around, for all of eternity.  I can see an implementation recommendation note because it makes sense, but, if we use the old rule of "for interoperability" I don't see specifying the order of records as necessary.

I also think that goats have already left the burning barn on this.  Going forward code might put the DNAME ahead of the CNAME, but if past code doesn't, going forward code must account for that.  It's the same for compression of domain names in RDATA - despite originally being limited to the first set of resources records, later code expanded it to the point that there's a set of resource records than must be expected to be compressed incoming and never compressed outgoing.

All in all, I think the suggestion makes sense.  But there are other cases where the original definitions are "too loose for comfort" to fix as well.  And, to spread fear, uncertainty and doubt, once we try to plug holes there's the ever-present chance we create a rift in the protocol.

Not to mention the difficulties in writing so-called clarification documents.  They aren't all that pleasant...