Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

From: 神明達哉 <[email-masked]>
Date: Fri, 2 Dec 2016 11:55:15 -0800

At Fri, 25 Nov 2016 19:50:48 -0500,
tjw ietf <[email-masked]> wrote:

> Please review the draft and offer relevant comments. Also, if someone feels
> the document is *not* ready for publication, please speak out with your
> reasons.
>
> *Also*, if you have any opinion on changing the document named from
> 'refuse-any' to 'minimal-any', please speak out.

I've read the 03 version of the document.  I do *not* think this is
ready for publication since I still believe we should not abuse HINFO
for this purpose as I argued a year ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
(But other than that I think the document is quite well written).

As for renaming the file, I don't have a strong opinion, but we expect
a bigger issue like HINFO can lead to more revisions, it would be good
to rename it at this opportunity in order to avoid confusion for
future readers.

Some specific comments on the text:

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
       the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me, partly because
  'a subset of RRSets' should include 'one of RRSets' and can thus be
  redundant, and partly because 'subset of RRSets" might sound related
  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
  So I'd suggest changing this one of the following:
  - "one or a few of RRSets (but not all of them)"
  - "one or a few of RRSets"
  - "a subset of RRSets"
  I personally prefer the first most although it may be too verbose.

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous
  bullet).

- Section 4

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, a valid RRSIG for the
   RRSets in the answer (or authority if answer is empty) section MUST
   be returned.

  Does this also apply to a synthesized HINFO (if so, by dynamically
  signing it?)?

- Section 6

   In the case where a zone that contains HINFO RRSets is served from an
   authority server that does not provide conventional ANY responses.

  This may be just because of my English literacy, but on my first
  read it was quite confusing to me; I first thought the second 'that'
  was a relative pronoun, which would make this text an incomplete
  sentence.  If there was a comma after 'server' that would be more
  readable for me.

- Section 7: a minor typo, s/implimentations/implementations/

   not return all RRSIGS.  In the wild there are implimentations that

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 2 Dec 2016 11:56:40 -0800

At Mon, 28 Nov 2016 11:25:11 +0100,
Matthijs Mekking <[email-masked]> wrote:

> 2. People expressed that they would like to see ANY over TCP stick to
> the original (undefined) behavior, that is to return all RRsets at the
> QNAME. Joe replied that this is still possible with this document
> because the mechanism is "a big giant MAY", but still I think it makes
> sense to call out explicitly that the behavior MAY differ depending on
> the transport protocol.

+1 (forgot to include this point in my previous message).

--
JINMEI, Tatuya

---

From: "John Levine" <[email-masked]>
Date: 2 Dec 2016 21:29:19 -0000

>for this purpose ...

I have to agree.  I have DNS servers that send actual useful HINFO records.

If you're going to abuse an existing rrtype, an obvious candidate is
NULL (type 10) which has been experimental for 30 years and has never
been used for anything since some pre-RFC 1035 experiments.  

Or burn a code point and invent a NOTANY record.

R's,
John

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Fri, 2 Dec 2016 22:07:26 +0000

Your English literacy is fine. I believe sentences which are logically connected into one super-sentence have been accidentally severed into one sentence and one non-sentence.

That super-sentence would be:

"In the case where a zone that contains HINFO RRSets is served from an authority server that does not provide conventional ANY responses, it is possible that the HINFO RRSet in an ANY response, once cached by the initiator, might suppress subsequent queries from the same initiator with QTYPE=HINFO."

This is then followed by another, largely redundant sentence:

"The use of HINFO in this proposal would hence have effectively mask [sic] the HINFO RRSet present in the zone."

I suggest a rewording that collapses the whole paragraph into a single, tighter sentence:

"The HINFO RRset provided as an ANY response, as per this specification, when cached by the initiator, may suppress subsequent QTYPE=HINFO queries for the same QNAME, thus effectively masking, from that initiator, an explicit HINFO RRset present in the zone."

														- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of ????
Sent: Friday, December 02, 2016 2:55 PM
To: tjw ietf
Cc: dnsop
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

At Fri, 25 Nov 2016 19:50:48 -0500,
tjw ietf <[email-masked]> wrote:

> Please review the draft and offer relevant comments. Also, if someone 
> feels the document is *not* ready for publication, please speak out 
> with your reasons.
>

I've read the 03 version of the document.  I do *not* think this is ready for publication since I still believe we should not abuse HINFO for this purpose as I argued a year ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
(But other than that I think the document is quite well written).

As for renaming the file, I don't have a strong opinion, but we expect a bigger issue like HINFO can lead to more revisions, it would be good to rename it at this opportunity in order to avoid confusion for future readers.

- Section 3

- Section 4

- Section 4

- Section 6

--
JINMEI, Tatuya

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 3 Dec 2016 12:44:47 -0500

> On Dec 2, 2016, at 2:55 PM, 神明達哉 <[email-masked]> wrote:
> 

We have some implementation experience with this and the fact that we return a 
Record that is parsed and displayed in human readable format has proven valuable in 
dealing with “interoperability” problems. 
A number of “abusers” of ANY queries have seen this read the draft and said 
       - yep I should have a fallback
or    - asking for exactly what I need is better way 

So what other RFC1034/5 defined type are you willing to throw under the bus? 
Paul Wouters accused us of doing in at the DNS-Oarc workshop in Montreal), 
these exchanges from the Q/A part of the presentation are enlightening
https://youtu.be/Gt9VUPDoZk0?t=1h24m53s

> to rename it at this opportunity in order to avoid confusion for

I’m hoping the version coming after this WGLC be advanced to the IESG/IETF LC 
so renaming at this point serves limited purpose. 

>  I personally prefer the first most although it may be too verbose.
I  think the best way to address this to be consistent with Section 4 is to say 
“one RRset” and be done with it 

>  subset of RRSets" stated in the preceding section (see the previous
see above 

>  Does this also apply to a synthesized HINFO (if so, by dynamically
Yes 

>  sentence.  If there was a comma after 'server' that would be more

Joe and I will take a stab of making that clearer 

>   not return all RRSIGS.  In the wild there are implimentations that
Yep need to fix that 
Thank you for your excellent review. 

Olafur

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2016 22:08:55 -0000

>So what other RFC1034/5 defined type are you willing to throw under the bus? 

Here's a few, all well defined and very dead, with what's in the rrdata:

MD (3) hostname
MF (4) hostname
MB (7) hostname that's interpreted as a mailbox
MG (8) hostname that's interpreted as a mailbox
MR (9) hostname that's interpreted as a mailbox

and of course

SINK (40) the kitchen sink

(I suspect Don intended SINK as an April 1 RFC, but whether or not he
did, it's got a type number.)

R's,
John

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 6 Dec 2016 13:17:29 +0100 (CET)

----- Original Message -----
> From: "神明達哉" <[email-masked]>
> To: "tjw ietf" <[email-masked]>
> Cc: "dnsop" <[email-masked]>
> Sent: Friday, 2 December, 2016 20:55:15

>  I personally prefer the first most although it may be too verbose.

Just a nitpick about using "subset" in general - it should be either
"non-empty subset" (or something else) so I like "one or a few" more.

Cheers,
Ondrej

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Dec 2016 23:04:18 +0000

On Tue, Nov 29, 2016 at 09:10:02AM +0100,
 Matthijs Mekking <[email-masked]> wrote 
 a message of 196 lines which said:

> > This is operational choice, if we call that out do we also call
> > out that answer may depend on address, TSIG etc ?
> 
> No, just TCP :)

Why not also when cookies are used? Like TCP, they protect against
reflection attacks.

---

From: Tony Finch <[email-masked]>
Date: Thu, 8 Dec 2016 11:25:04 +0000

> Why not also when cookies are used? Like TCP, they protect against

My reason for deploying minimal-any was not for direct reflection
attacks, because RRL already deals with direct reflection attacks.

I wanted to avoid sending truncated UDP responses to legit resolvers.

When lots of legit recursive resolvers are being attacked with ANY queries
for one of my zones, I don't want them to hammer my authoritative servers
with TCP connections. So, minimal-any means they go away happy with a
small answer, and everything stays on UDP.

Eventually I expect legit resolvers to deploy cookies, and I still want
to send them small answers to avoid TCP when an ANY attack happens.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Forties, Cromarty, Forth: Southwest 5 or 6, decreasing 4 at times. Slight or
moderate, occasionally rough at first in Forties. Fair. Good.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 08 Dec 2016 20:09:00 -0500

The draft seems almost ready to go to the IETF. However, there are still 
a few areas that need work.

As others have discussed, the filename really has to change. Like it or 
not, RFCs get associated with the last draft name that produced it, and 
"refuse-any" is just wrong for this document.

The current title, "Providing Minimal-Sized Responses to DNS Queries 
with QTYPE=ANY", makes sense to DNS experts but probably not to anyone 
else. Proposed change: "Providing Minimal-Sized Responses to DNS Queries 
That Have a Query Type of 'ANY'". It's longer, but it will make much 
more sense to others.

The organization of the document makes it hard for an implementor to 
decide which text is about the first option (send back one or a subset 
of real RRs), which is about the second option (send back a synthesized 
HINFO), and which refers to both. This can be alleviated by reorganizing 
the existing text.
   - Move "This proposal specifies two different modes of behaviour by 
DNS..." and the two bullet points out of Section 3 and into the top of 
Section 4.
   - Split Section 4 into three subsections: "4.1 Select a Subset", "4.2 
Synthesize an HINFO Record", and "4.3 Topics Relevant to Either 
Deployment Option".
   - Move the text from Section 6 into the new Section 4.2.

On the topic of HINFO versus another RRtype, I think HINFO is fine. The 
fact that some servers use HINFO is a red herring: the answers described 
in this document only are returned for QTYPE=ANY, not for QTYPE=HINFO. 
Having said that, the following text from Section 6 seems wrong: 
"Authority-server operators who serve zones that rely upon conventional 
use of the HINFO RRTYPE MAY sensibly choose not to deploy the mechanism 
described in this document or select another type". A much more logical 
approach would be "Authority-server operators who serve zones that rely 
upon conventional use of the HINFO RRTYPE SHOULD choose to respond with 
a subset of the RRtypes, as described in Section 4.1".

The text "Except as described in this section, the DNS responder MUST 
follow the standard algorithms when constructing a response" is unclear 
unless you call out RFC 1035.

In Section 5, it is not clear why an initiator MAY cache the response. I 
believe it SHOULD cache the response as a normal DNS response.

--Paul Hoffman

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 12 Dec 2016 09:44:53 +0100

> Why not also when cookies are used? Like TCP, they protect against

As Joe pointed out earlier, the document already does not prohibit you
from doing so. But some of us would like to have that explicitly called
out: that you can still implement this feature *and* do something else
under some conditions. The example given is allowing original behavior
when the transport protocol is TCP, but obviously it is not limited to
just that one example.

Best regards,
  Matthijs

---

From: 神明達哉 <[email-masked]>
Date: Thu, 22 Dec 2016 10:19:42 -0800

Sorry for the delayed response.  I've been unusually busy for these
several weeks...

At Sat, 3 Dec 2016 12:44:47 -0500,

> So what other RFC1034/5 defined type are you willing to throw under the bus?

(If synthesizing an otherwise-non-existent type of RRset is non
debatable) personally, I'd rather propose introducing a new RR type
specifically for this purpose so it's guaranteed to not cause
conflict or confusion.  "human readability with currently available
tools (e.g., a currently distributed version of dig)" is a well-known
excuse in cases like this or TXT abusers, but at least for a standard
track IETF protocol I believe we should take a more long-term view;
once we define the new type it won't take too long until common tools
like dig, drill, etc will catch up.  Until then relatively skilled
users can google what 'TYPE259' means and finds it's returned as
defined in RFC83xx.

> “one RRset” and be done with it

Works for me.  (But some others might want to avoid to be too
restrictive).
> >  Does this also apply to a synthesized HINFO (if so, by dynamically

Okay.  My objection to using HINFO in the first place aside, as long
as this hack is documented I think the doc should explicitly note it.

--
JINMEI, Tatuya