Subject: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 10 Sep 2018 07:48:22 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-refuse-any-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am balloting YES, because it is good to have these techniques available, but
I also have some comments that I would like to see addressed or rebutted.

The Shepherd writeup does not say why 1034/1035 are not mentioned in the
Abstract.  Also, the phrase "updates [103x] by" does not appear in the
Introduction, leaving just section 7 to describe the changes.

The document doesn't really make it clear whether the "[t]he operator [...]
might choose not to respond to such queries" is restating an existing
specification from some other document or making a new statement.

Section 1.1

As Mirja notes, draft-ietf-dnsop-terminology-bis is likely to replace 7719
by the time this document's publication process finishes.

Section 2

It seems like the intended takeaway here is that there's a balance or
tradeoff to had between the "good" uses (efficiency of getting all desired
data at once) and "bad" ones (amplification), with mining for zone data
being a "dual-use technology".  The text doesn't really help the reader
reach that conclusion, though -- a few extra words at the start of each
paragraph might help, like the "legitmiately used" in the very first one,
or "On the other hand, ANY queries are frequently abused to [...]" might
help set the intended tone.

Section 4

Should "return a conventional ANY response" be listed or mentioned here?

Section 4.2

   [...] The
   specific value used is hence a familiar balance when choosing TTL for
   any RR in any zone, and be specified according to local policy.

nit: Is there a missing word or three before "be"?

   DATA described in this seection to distinguish between synthesised
   and non-synthesised HINFO RRSets.

nit: "section"

I'm a little surprised to see a "SHOULD NOT" for relying the RDATA 'CPU'
contents of "RFCXXXX" for the final RFC number, since I can't come up with
an other reason why that CPU value would be used.  But I do not object to it.

Section 4.4

Why are we enumerating transports instead of talking about the properties
they provide?  We've got multiple new transports in the works, and it would
be a shame to ignore them out of the gate.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 10 Sep 2018 19:02:45 -0500

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

<clip>

> be a shame to ignore them out of the gate.

It's probably also worth pointing out (chiming in on Benjamin's ballot)
that talking about transport properties would help us make sure we keep
those properties in mind when we work on new transports :-) ...

Spencer

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 13 Sep 2018 08:51:45 +1100

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

--->
Section 1 has following text

  The DNS specification [RFC1034] [RFC1035] does not include specific
   guidance for the behaviour of DNS servers or clients in this
   situation.  This document aims to provide such guidance.

Is that sufficient for readers ?

> It is stating an operating practice

Section 1.1
> If that is published I hope RFC editor Auth48 phase will catch it

> help set the intended tone.
IMHO there is no "good" use of ANY in the world but by the operator of the
server,
all other uses are based on misunderstanding or abuse,
others disagree.
Since this document was started the abuse of ANY has decreased against the
operators that have adopted the techniques in the document
but at the same time moved more to operators that do not support it.

Section 4
> IMHO no

> nit: Is there a missing word or three before "be"?
"to be " ?

>    and non-synthesised HINFO RRSets.
good catch

> thanks

> This is a good point DNS people have in the past only thought in the
context of two transports UDP and TCP
but the world is changing.
We will work on text that replaces TCP with "transport properties" as
Spencer has suggested.

-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 12 Sep 2018 17:13:42 -0500

Hi Ólafur,

Before I get into the inline comments, I should note something that I only
noticed after I posted my ballot position: although everyone I know always
refers to this query as "ANY", that's the command-line interface in dig(1),
etc., it seems that the specified string to refer to this query is
officially "*".  That's what 1035 uses and that's what's in the IANA
registry; RFC 6895 has a clarification in a parenthetical "* (ALL/ANY)",
but I didn't see much precedent for only using "ANY" in an RFC to refer to
this query.  To be clear, I don't object to using that as the primary term
-- it is, after all, the common usage!  But perhaps it's worth a short
mention at the start that we use "ANY" to refer to QTYPE 255, registered as
"*".  The reader can perhaps infer this fact from the IANA considerations
that update that entry in the registry to also refer to this document, but
it would be nice for the relationship to be more explicit.

> Is that sufficient for readers ?

I was coming at this from the perspective of the proposed IESG statement on
the use of the "Updates" (see thread at
https://www.ietf.org/mail-archive/web/ietf/current/msg109106.html), the
wording or which would imply that a stronger statement is appropriate in
this document.  But the linked proposal is not yet in effect, and as such
is non-binding.

> It is stating an operating practice

Is this behavior permitted by the existing RFCs, or a grey area, or in
contravention to the spec?

> but at the same time moved more to operators that do not support it.

Ah, interesting.  This was a non-blocking comment anyway, so (as Spencer is
acclimating us all to say) "do the right thing".

> > Should "return a conventional ANY response" be listed or mentioned here?

Okay.

> We will work on text that replaces TCP with "transport properties" as

Great; thanks!

-Benjamin

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 13 Sep 2018 09:38:54 +1100

On Thu, Sep 13, 2018 at 9:13 AM, Benjamin Kaduk <[email-masked]> wrote:

> That is a great point something like:
RFC1035 defined "*" as type 255 but DNS applications have used the "ANY"
word to refer to that type code"

> On Thu, Sep 13, 2018 at 08:51:45AM +1100, Ólafur Gušmundsson wrote:
> > > I am balloting YES, because it is good to have these techniques
> available,
> > > but
> thanks for the background,

> contravention to the spec?

Good question answer depends on who you ask
I say all three

> YES yes

> > > an other reason why that CPU value would be used.  But I do not object
> to
> > > it.
> > >
> > thanks
> >
> >
> > > Section 4.4
> > >

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 15 Sep 2018 12:12:28 -0500

> word to refer to that type code"

That works to get the point across, sure.

Thanks,

Benjamin