Subject: [DNSOP] order of records in DNAME responses

From: Evan Hunt <[email-masked]>
Date: Thu, 23 Feb 2017 23:24:32 +0000

RFC 6672 saith:

    A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME
    RR is synthesized and included in the answer section when the DNAME
    is employed as a substitution instruction. The DNSSEC specification
    ([RFC4033] [RFC4034] [RFC4035]) says that the synthesized CNAME does
    not have to be signed.  The signed DNAME has an RRSIG, and a validating
    resolver can check the CNAME against the DNAME record and validate the
    signature over the DNAME RR.

The phrase "included in", as opposed to "appended to", provides no guidance
about the order in which records appear, so presumably it's legal to have
the synthesized CNAME appear first and the DNAME from which it was
synthesized afterward.

Most implementations, however, do send the DNAME first.  We had a problem
with BIND a while back when we encountered a server that didn't.  BIND
processes the RRsets in an answer in the order they're received (I suspect
nearly all resolvers do this).  In this case, the decisions about how to
validate and cache the CNAME went wrong because we didn't have the flag set
saying we'd previously seen a DNAME.

We rejiggered the code so it wouldn't care about the order of records
anymore (incidentally, and embarrassingly, introducing another bug in the
process, but that's another story).  It would have been simpler and more
painless if we could have just treated this condition as a FORMERR.

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?

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Matthäus Wander <[email-masked]>
Date: Fri, 24 Feb 2017 11:40:26 +0100

> 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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Feb 2017 14:46:28 +0000

>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...

---

From: Evan Hunt <[email-masked]>
Date: Fri, 24 Feb 2017 17:00:32 +0000

> 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.

> 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.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Feb 2017 17:24:04 +0000

>    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).

>    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.

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 24 Feb 2017 17:32:58 +0000

> On Feb 23, 2017, at 3:24 PM, Evan Hunt <[email-masked]> wrote:
> 

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

---

From: Evan Hunt <[email-masked]>
Date: Fri, 24 Feb 2017 17:35:19 +0000

On Fri, Feb 24, 2017 at 02:46:28PM +0000, 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...

---

From: Edward Lewis <[email-masked]>
Date: Fri, 24 Feb 2017 17:42:53 +0000

> 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. ;)

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 25 Feb 2017 14:52:15 -0500

> On Feb 24, 2017, at 12:35 PM, Evan Hunt <[email-masked]> wrote:
> 

While I would love to say Yes to above, that can not be any stronger than “SHOULD” 
The old RFC’s are much less prescriptive than modern ones. 
If we ever do a RFC2181-bis or followup work then this should be one of the topics 
There are basically two ways to handle it 
-  Prescribe order 
- Dicate that whole section must be consumed and “ordered” before processing.

One corner case that I seen on couple of occasions is CNAME chain out of order, 
I have no idea how that can happen … 

> to step on by declaring we didn't mean for it to be legal.
I was around the time DNAME was defined, and my recollection was that
CNAME after DNAME was so obvious that no-one thought is was needed to specify. 

> Well, that's why I started with an email thread…

Thank you for bringing real issue to WG

Olafur

---

From: Edward Lewis <[email-masked]>
Date: Mon, 27 Feb 2017 15:45:39 +0000

On 2/25/17, 14:52, "Olafur Gudmundsson" wrote:

>...can not be any stronger than “SHOULD”...

And that is why it remains you "MUST" be liberal in what you accept. ;)