Subject: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-ordered-answers-00.txt

From: "Joe Abley" <[email-masked]>
Date: Fri, 09 Oct 2015 08:42:18 -0400

Hi all,

In a fit of zeal I wrote up what I thought was a reasonable 
clarification to 1034/1035 with respect to the ordering of RRSets within 
sections of a response to a DNS QUERY, prompted by the discussions on 
this list in August, to which maybe this link is a useful pointer:

https://mailarchive.ietf.org/arch/msg/dnsop/7KoE8Dr-SxuNToskxbvAwJ3BQLQ

Mark and Paul gave me some opinions as I was writing this up, that I may 
or may not have represented accurately in the text. I think the advice 
is reasonable, but thoughts from the throng as to (a) whether this was 
worth writing down and (b) whether what I wrote is nonsense would be 
appreciated.

Joe

Forwarded message:

> From: [email-masked]
> To: Joe Abley <[email-masked]>
> Subject: New Version Notification for 
> draft-jabley-dnsop-ordered-answers-00.txt
> Date: Fri, 09 Oct 2015 05:39:13 -0700
>
>
> A new version of I-D, draft-jabley-dnsop-ordered-answers-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
>
> Name:		draft-jabley-dnsop-ordered-answers
> Revision:	00
> Title:		Ordering of RRSets in DNS Messages
> Document date:	2015-10-09
> Group:		Individual Submission
> Pages:		12
> URL:            
> https://www.ietf.org/internet-drafts/draft-jabley-dnsop-ordered-answers-00.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-jabley-dnsop-ordered-answers/
> Htmlized:       
> https://tools.ietf.org/html/draft-jabley-dnsop-ordered-answers-00
>
>
> Abstract:
> The existing Domain Name System (DNS) specifications lack some
> clarity in their description of the process by which individual
> sections of a DNS message are constructed.
>
> This document updates RFC 1034 and RFC 1035 to provide a clearer
> specification, consistent with deployed implementations.
>
>
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Oct 2015 10:54:15 -0400 (EDT)

On Fri, 9 Oct 2015, Joe Abley wrote:

> In a fit of zeal I wrote up what I thought was a reasonable clarification to 
> 1034/1035 with respect to the ordering of RRSets within sections of a 
> response to a DNS QUERY, prompted by the discussions on this list in August, 
> to which maybe this link is a useful pointer:

> Mark and Paul gave me some opinions as I was writing this up, that I may or 
> may not have represented accurately in the text. I think the advice is 
> reasonable, but thoughts from the throng as to (a) whether this was worth 
> writing down and (b) whether what I wrote is nonsense would be appreciated.

I find it strange that you suggest ordering matters for the Answer
section but not the Authoritative section. It seems that we will just
get more assumptions from code that order matters there too, and 10
years from now we are writting this document again, but for the
Authoritative section.

Paul

---

From: "Joe Abley" <[email-masked]>
Date: Fri, 09 Oct 2015 11:04:17 -0400

On 9 Oct 2015, at 10:54, Paul Wouters wrote:

>> clarification to 1034/1035 with respect to the ordering of RRSets 
>> within sections of a response to a DNS QUERY, prompted by the 
>> discussions on this list in August, to which maybe this link is a 
>> useful pointer:
>
>> Mark and Paul gave me some opinions as I was writing this up, that I 
>> may or may not have represented accurately in the text. I think the 
>> advice is reasonable, but thoughts from the throng as to (a) whether 
>> this was worth writing down and (b) whether what I wrote is nonsense 
>> would be appreciated.
>

The principal reason that ordering seems empirically to matter in the 
answer section is that that's the section that stub resolvers care 
about. It's really the stub-recursive interaction that matters, here.

With a mind towards running code, if we specified that order mattered in 
the additional section we'd essentially be making all major 
implementations non-compliant in some way. There's no indication that 
different ordering strategies in the additional section have any impact 
on deployed resolvers (and perhaps we can help ensure that none come to 
light in the future by making the specification clear).

For responses without DO=1 I don't know of a case where we see more than 
one RRSet in the authority section, so ordering is a no-op there in any 
practical sense.

Joe

---

From: Shumon Huque <[email-masked]>
Date: Fri, 9 Oct 2015 11:08:44 -0400

On Fri, Oct 9, 2015 at 10:54 AM, Paul Wouters <[email-masked]> wrote:

> In a fit of zeal I wrote up what I thought was a reasonable clarification
>> to 1034/1035 with respect to the ordering of RRSets within sections of a
>> response to a DNS QUERY, prompted by the discussions on this list in
>> August, to which maybe this link is a useful pointer:
>>
>
>> or may not have represented accurately in the text. I think the advice is
It already seems to matter for some implementations. My colleague, Casey
Deccio, has uncovered a case where a certain resolver implementation fails
to authenticate negative responses when NSEC/NSEC3 signatures appear before
the data records in the authority section of responses from an upstream
forwarder. I hope he'll elaborate on more specific details.

(Not implying we should sanction this behavior; just reporting what's been
observed in the field).

Shumon Huque.