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

[Ólafur Guðmundsson <[e-mail]>]

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

> 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.
>
> 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:
> > On Tue, Sep 11, 2018 at 1:48 AM, Benjamin Kaduk <[e-mail]> wrote:
> >
> > > 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.
> > >
> >
> > --->
> > 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 ?
>
> 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.
>
> thanks for the background,


> >
> > > 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.
> > >
> > It is stating an operating practice
>
> Is this behavior permitted by the existing RFCs, or a grey area, or in
> contravention to the spec?
>

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


>
> > 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.
> > >
> > > If that is published I hope RFC editor Auth48 phase will catch it
> >
> >
> > > 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.
> > >
> > >
> > 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.
>
> Ah, interesting.  This was a non-blocking comment anyway, so (as Spencer is
> acclimating us all to say) "do the right thing".
>
> YES yes


> > Section 4
> > >
> > > Should "return a conventional ANY response" be listed or mentioned
> here?
> > >
> > IMHO no
>
> Okay.
>
> >
> > > 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"?
> > >
> > "to be " ?
> >
> > >
> > >    DATA described in this seection to distinguish between synthesised
> > >    and non-synthesised HINFO RRSets.
> > >
> > > nit: "section"
> > >
> > good catch
> >
> >
> > >
> > > 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.
> > >
> > thanks
> >
> >
> > > 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.
> > >
> > >
> > 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.
>
> Great; thanks!
>
> -Benjamin
>



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