Subject: [DNSOP] draft-jabley-dnsop-ordered-answers

From: "Joe Abley" <[email-masked]>
Date: Wed, 04 Nov 2015 21:37:23 -0500

Hi all,

I couldn't quite interpret the questions and hums in the room; was the 
consensus

(a) this clarification is not needed; the existing spec is clear enough, 
or

(b) a clarification might be useful, but the proposed clarification in 
the document is wrong, or

(c) something else?

If it's (b), I could collect more of the kinds of insights that were 
provided at the mic and update the proposal.

If it's (a), I can happily just shut up about and move on with other 
things :-)

Joe

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 5 Nov 2015 02:20:14 -0500

On Wed, Nov 4, 2015 at 9:37 PM, Joe Abley <[email-masked]> wrote:
> (a) this clarification is not needed; the existing spec is clear enough, or
>
> (b) a clarification might be useful, but the proposed clarification in the
> document is wrong, or
>
> (c) something else?
>
> If it's (a), I can happily just shut up about and move on with other things
> :-)

I believe that in theory the result of the hum was (a) but it may be
that many people thought (b)...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Thu, 5 Nov 2015 22:26:22 +0900

> If it's (a), I can happily just shut up about and move on with other

IMHO, if a clarification is needed, it's that a client that depends on
the order of the RRsets in an answer MUST NOT do so.

Ray

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 05 Nov 2015 15:54:41 +0000

On Thu, 05 Nov 2015 13:26:22 +0000,
> the order of the RRsets in an answer MUST NOT do so.

  Wouldn't it be a simpler clarification to say that a client MUST NOT
  depend on the order of the RRsets in an answer?

  /Niall

---

From: "Joe Abley" <[email-masked]>
Date: Thu, 05 Nov 2015 11:30:07 -0500

On 5 Nov 2015, at 2:20, Donald Eastlake wrote:

>> things

I shall wait instruction from the chairs as to their opinion.

In case it wasn't clear from Andrew's slides and discussion, the reason 
for asking for adoption was to harvest the combined experience of the 
working group in order to make the proposal make sense, not to push a 
particular solution.

Joe

---

From: "Joe Abley" <[email-masked]>
Date: Thu, 05 Nov 2015 12:42:45 -0500

> depend on the order of the RRsets in an answer?

Sure, the solution could be any number of things.

But what I heard clearly in the room (and what I saw on the mailing 
list) is that there are multiple interpretations of the base spec, and 
that there is deployed code that breaks as a result. This to me suggests 
a need for clarification, regardless of what the clarification says.

Given that perspective, I remain confused as to why there was a strong 
hum against providing clarification. It does seem possible that people 
were humming against the specific proposal in the document, and not the 
need for clarification in general.

As I mentioned before I'm not trying to beat a dead horse, here. I just 
want to make sure I understand what question people thought they were 
being asked.

Joe

---

From: Ray Bellis <[email-masked]>
Date: Fri, 6 Nov 2015 06:21:00 +0900

>   depend on the order of the RRsets in an answer?

That's what I meant (blame jetlag).

Ray

---

From: Ray Bellis <[email-masked]>
Date: Fri, 6 Nov 2015 07:11:55 +0900

On 06/11/2015 07:04, Paul Vixie wrote:

> there's an installed base consisting of over a billion stubs and a few tens of 
> millions of recursives who will fail to parse your response if the CNAME comes 
> after the thing it points to.
> 
> generally speaking, that has to be documented, and has first-mover advantage.

I sit corrected.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Nov 2015 09:13:57 +1100

> That's what I meant (blame jetlag).

The RFC 1034 actually says:

	    If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

	    Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

Now I fail to see how one can "copy the CNAME RR" on pass one and
then "copy all RRs which match QTYPE" on a later pass and end up
with the "second set of records before the CNAME".

This is not "add to a list to be later copied to the answer section".
This is do it right now.

Now I know that many implementations just add records to lists and
then render them all at once but if that does not produce the same
results as just copying them when instructed then the implementation
is broken.

I also know that resolver should be more robust.

I also know that there are a many magnitudes more resolvers than
servers and that fixing (or declaring the servers broken and then
fixing for Andrew) is the best thing to do.

Mark

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Nov 2015 14:04:20 -0800

-- 
P. Vixie

---

From: Shane Kerr <[email-masked]>
Date: Fri, 6 Nov 2015 12:07:22 +0900

Joe,

On Thu, 05 Nov 2015 12:42:45 -0500

> a need for clarification, regardless of what the clarification says.

Yes, I agree completely.

Clarifying may result in a large installed base of software that does
not implement the rules properly. But the alternative is a large
installed base of software that does not inter-operate. Sometimes. In
various confusing ways. Except when it does.

> need for clarification in general.

I was in the room, and mildly surprised that there was a strong hum
against clarification.
 
> want to make sure I understand what question people thought they were 

Good point. Perhaps people thought they were being asked to approve a
specific set of recommendations and did not like that? If that is the
case, fine, but lets pick a DIFFERENT set of recommendations then.

If people were opposed to adopting ANY straightforward clarification,
let me ask them to please reconsider. I beg of you all. Think of the
children.

Cheers,

--
Shane

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Nov 2015 23:00:07 -0500

On Thu, Nov 05, 2015 at 12:42:45PM -0500, Joe Abley wrote:
> But what I heard clearly in the room (and what I saw on the mailing list) is
> that there are multiple interpretations of the base spec, and that there is
> deployed code that breaks as a result. This to me suggests a need for
> clarification, regardless of what the clarification says.

For whatever it's worth, I had the same reaction.  Probably I did a
bad job presenting the point.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bob Harold <[email-masked]>
Date: Fri, 6 Nov 2015 13:05:00 -0500

On Thu, Nov 5, 2015 at 5:04 PM, Paul Vixie <[email-masked]> wrote:

> To keep things working, I agree that that servers MUST order the answers.

I thought of suggesting that "clients SHOULD accept answers in any order".
But on second thought, this increases code complexity, for no real
benefit.  And we will probably see more low-compute-power devices doing
some basic DNS lookups that need to keep code to a minimum.

-- 
Bob Harold

---

From: Paul Vixie <[email-masked]>
Date: Fri, 06 Nov 2015 10:09:37 -0800

> some basic DNS lookups that need to keep code to a minimum.

i agree with this conclusion but not with your reasons as stated.

as marka pointed out up-thread, RFC 1035 already describes answer construction 
in a certain order, and in that sense, the jabley--ordered-answers draft is 
merely a clarification in case anyone misunderstood 1035's ordering 
implications.

however, low-compute-power devices in 2015 already have 10X the computing 
power of the VAX 8350 i ran all of DEC.COM's e-mail through (for ~130K 
employees) in 1989. we don't have to worry about their computational burden 
now, and that trend will accelerate. which is a good thing, because DNSSEC 
must become ubiquitous, all the way to the edge.

-- 
P. Vixie

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Nov 2015 13:22:09 +0100

On Wed, Nov 04, 2015 at 09:37:23PM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 26 lines which said:

> I couldn't quite interpret the questions and hums in the room; was
> the consensus

>From the PowerDNS Recursor's author, whose DNSSEC version of the
software sometimes returns RRSIG before A:

"We shuffle and I'm not going to special case it for weak
implementations."

:-)

---

From: Paul Wouters <[email-masked]>
Date: Fri, 27 Nov 2015 08:16:53 -0500

RFC 1122: "Be liberal in what you accept, and conservative in what you send").

It's cute, but it will lead to interop issues. It will also make debugging more annoying for humans.

Paul

Sent from my iPhone

> On Nov 27, 2015, at 07:22, Stephane Bortzmeyer <[email-masked]> wrote:
>

---

From: Ray Bellis <[email-masked]>
Date: Fri, 27 Nov 2015 14:14:07 +0000

> debugging more annoying for humans.

See also draft-thomson-postel-was-wrong-00

<https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00>

Ray

---

From: Mark Andrews <[email-masked]>
Date: Sat, 28 Nov 2015 09:32:12 +1100

> <https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00>

DNSSEC only says the signature should stay together with the data.
It does not specify the order of the data and the signatures as far
as I have seen.

As for being liberal in what you accept when it is out of spec,
that often causes more problems that it fixes.  It's also hard to
wind back if you want to make things more strict.

We fixed a bug which allowed us to start correctly rejecting non
"aa=1" responses and we had to start re-accepting them as high
profile servers were failing to set "aa=1" on all their servers.

Then you have Panodra.tv's DNS servers which are absolute pieces
of garbage spewing out non compliant answers but if you start
rejecting them there is all hell to pay.  They don't do DNS or EDNS.

% dig pandora.tv ns @61.111.8.236 +noad +noedns

; <<>> DiG 9.11.0pre-alpha <<>> pandora.tv ns @61.111.8.236 +noad +noedns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51035
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: Message has 27 extra bytes at end

;; QUESTION SECTION:
;pandora.tv.			IN	NS

;; ANSWER SECTION:
pandora.tv.		300	IN	NS	n1.pandora.tv.
pandora.tv.		300	IN	NS	n2.pandora.tv.
pandora.tv.		300	IN	NS	n5.pandora.tv.
pandora.tv.		300	IN	NS	n6.pandora.tv.
pandora.tv.		300	IN	NS	n7.pandora.tv.

;; Query time: 218 msec
;; SERVER: 61.111.8.236#53(61.111.8.236)
;; WHEN: Sat Nov 28 09:12:32 EST 2015
;; MSG SIZE  rcvd: 140

% dig pandora.tv ns @61.111.8.236 +nocookie
;; Got bad packet: FORMERR
140 bytes
8c 39 85 a0 00 01 00 05 00 00 00 01 07 70 61 6e          .9...........pan
64 6f 72 61 02 74 76 00 00 02 00 01 c0 0c 00 02          dora.tv.........
00 01 00 00 01 2c 00 05 02 6e 31 c0 0c c0 0c 00          .....,...n1.....
02 00 01 00 00 01 2c 00 05 02 6e 32 c0 0c c0 0c          ......,...n2....
00 02 00 01 00 00 01 2c 00 05 02 6e 35 c0 0c c0          .......,...n5...
0c 00 02 00 01 00 00 01 2c 00 05 02 6e 36 c0 0c          ........,...n6..
c0 0c 00 02 00 01 00 00 01 2c 00 05 02 6e 37 c0          .........,...n7.
0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00          ................
00 00 00 00 00 00 00 00 00 00 00 00                      ............
% 

Now if we just start rejecting this garbage there will lots of
complaints but servers like this should just be wiped off the net.

Mark