On Thu, Sep 13, 2018 at 9:13 AM, Benjamin Kaduk <ka...@mit.edu> 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 <ka...@mit.edu> 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
