Re: [DNSOP] [Ext] order of records in DNAME responses
On 2/24/17, 12:35, "Evan Hunt" wrote: > Well, that's why I started with an email thread... I'm certainly *not* saying: "Don't do it!" (Sorry for the double negative.) But the hours spent writing the code to handle the issue might be less than the hours spent "producing" the clarification document. ;) smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] order of records in DNAME responses
On Fri, Feb 24, 2017 at 02:46:28PM +, Edward Lewis wrote: > 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. The order of RR's within an RRset is undefined and needs to remain so, but can there be constraints on the order of RRsets within a section? > 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 took us a very long time to encounter the first server that did CNAME-first. Most are going to do DNAME-first because it's simpler to code that way: it's easier to append to a message than insert something into the middle. IMHO the problem is now big enough to see, but still small enough to step on by declaring we didn't mean for it to be legal. > Not to mention the difficulties in writing so-called clarification > documents. They aren't all that pleasant... Well, that's why I started with an email thread... -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] order of records in DNAME responses
> On Feb 23, 2017, at 3:24 PM, Evan Hunt 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? Hi Evan, Even though I think "be liberal in what you accept" has been sort of harmful, I've always felt that the ordering of RRsets in a message should not matter at all. Also I worry that once we start clarifying ordering for the case you've proposed, we'll find a lot of other cases where ordering could be made to matter. CNAME and its target, for example. SRV and its target(s). RRSIGs and the records they cover. NSEC* enclosers. And so on. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: order of records in DNAME responses
On 2/24/17, 12:00, "DNSOP on behalf of Evan Hunt" wrote: >On Fri, Feb 24, 2017 at 11:40:26AM +0100, Matthäus Wander wrote: >> Do you mean clarifying as in "how it always was meant to be but stated >> in unclear words" or as in "change to protocol"? > >I meant the former. I wasn't involved, but I suspect that DNAME-first >was the intended behavior all along, and nobody thought to mention it. >However, if the group doesn't agree, then I guess I mean the latter. I wasn't there either...but in general, whenever you want to "clarify" what was intended by stating it explicitly, someone somewhere will claim it is a change and not a clarification. That was my experience with wild cards and to a lesser extent zone transfer (but someone else had and is why that document fell to me). > >> In the latter case, you'd still need code to parse responses from >> implementations that don't make assumptions about the order of records. > >What I'd like is to be able to send FORMERR with a clear conscience. Given the lax rules of the field, I'd lean to saying you can't. For DNSSEC this was a pain. Because we couldn't outlaw round robin we had to sort the records in the set as it arrived. All we could do was simplify the sorting comparison but not having to copy the data, sort, work, and dispose of the copy to retain the original ordering. The copy came to be 100% wasted cycles as you had to retain the original order. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] order of records in DNAME responses
On Fri, Feb 24, 2017 at 11:40:26AM +0100, Matthäus Wander wrote: > Do you mean clarifying as in "how it always was meant to be but stated > in unclear words" or as in "change to protocol"? I meant the former. I wasn't involved, but I suspect that DNAME-first was the intended behavior all along, and nobody thought to mention it. However, if the group doesn't agree, then I guess I mean the latter. > In the latter case, you'd still need code to parse responses from > implementations that don't make assumptions about the order of records. What I'd like is to be able to send FORMERR with a clear conscience. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] order of records in DNAME responses
On 2/23/17, 18:24, "DNSOP on behalf of Evan Hunt" 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... smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] order of records in DNAME responses
* Evan Hunt [2017-02-24 00:24]: > 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? Do you mean clarifying as in "how it always was meant to be but stated in unclear words" or as in "change to protocol"? In the latter case, you'd still need code to parse responses from implementations that don't make assumptions about the order of records. Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
