Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
RFC 8482

Note: This ballot was opened for revision 07 and is now closed.

Ignas Bagdonas Yes

(Spencer Dawkins) Yes

Benjamin Kaduk Yes

Comment (2018-09-10)
No email
send info
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.

Warren Kumari Yes

Mirja Kühlewind Yes

Comment (2018-09-10)
No email
send info
I'm wondering if it would make sense to provide stronger guidance that the conventional ANY response SHOULD be provided if TCP is used as TCP already provides a retrun routability proof...? Also maybe provide a refernce to RFC7766?

And one smallish comment: Would it make sense to refer draft-ietf-dnsop-terminology-bis-09 (or actually the soon to be new RFC) instead of RFC7719?

(Terry Manderson) Yes

Comment (2018-09-12)
No email
send info
Thank you for the work in this document, it is clear and certainly appropriate to consider the implications of ANY in light of operational and security concerns.

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alissa Cooper No Objection

Suresh Krishnan No Objection

Alexey Melnikov No Objection

Comment (2018-09-12)
No email
send info
I generally like this document, but I find it to be too wishy washy because of use of SHOULDs instead of MUSTs. I would have liked a bit more guidance early on about different choices or at least a statement that this is a rarely used feature and thus any choice is reasonably good.

(Eric Rescorla) No Objection

Comment (2018-09-12)
No email
send info
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5482



COMMENTS
S 3.
>      processing in order to send a conventional ANY response, and avoiding
>      that processing expense might be desirable.
>   
>   3.  General Approach
>   
>      This proposal provides a mechanism for an authority server to signal

Nit: authoritative.


S 4.3.
>      applications may be satisfied by this behaviour, the resulting
>      responses in the general case are larger than the approaches
>      described in Section 4.1 and Section 4.2.
>   
>      As before, if the zone is signed and the DO bit is set on the
>      corresponding query, an RRSIG RRSet MUST be included in the response.

This section seems to be one possible algorithm for implementing 4.1.
What am I missing?


S 7.
>      It is important to note that returning a subset of available RRSets
>      when processing an ANY query is legitimate and consistent with
>      [RFC1035]; it can be argued that ANY does not always mean ALL, as
>      used in section 3.2.3 of [RFC1035].  The main difference here is that
>      the TC bit SHOULD NOT be set on the response indicating that this is
>      not a complete answer.

This is a bit grammatically awkward, perhaps "response, thus
indicating"

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-09-10)
No email
send info
Thanks for the work that went into the mechanism, and especially to the early
deployers who found issues to be addressed. I have a small handful of comments
that the authors may wish to address prior to advancing the document to
publication.

---------------------------------------------------------------------------

§4.1:

>  A DNS responder which receives an ANY query MAY decline to provide a
>  conventional ANY response

Nit: "A DNS responder that receives..."

---------------------------------------------------------------------------

§4.2:

>  The CPU field of the HINFO RDATA SHOULD be set to RFCXXXX

Then, in §5:

>  A DNS initiator MAY suppress queries with QTYPE=ANY in the event that
>  the local cache contains a matching HINFO resource record with
>  RDATA.CPU field, as described in Section 4.

This looks like it's asking for a comparison. If such is the case, I think you
need to indicate whether the value being compared is done so in a case-sensitive
fashion. You probably also want to be pretty explicit about the literal string
value to be used (e.g., be clear that the value doesn't contain a space).

---------------------------------------------------------------------------

§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: This sentence appears to be missing a word. Perhaps "...and will be
specified..." or similar.

---------------------------------------------------------------------------

§4.2:

>  In particular, systems SHOULD NOT rely upon the HINFO
>  RDATA described in this seection to distinguish between synthesised
>  and non-synthesised HINFO RRSets.

Nit: "section"

More substantive comment: Since the CPU field SHOULD indicate this document,
implementations could reasonably infer that the HINFO RRSet is synthesized based
on its value, right? That seems worth mentioning here.

---------------------------------------------------------------------------

§5:

>  A DNS initiator which sends a query with QTYPE=ANY and receives a

Nit: "...initiator that sends..."

Martin Vigoureux No Objection