Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
draft-ietf-dnsop-refuse-any-07

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..."

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.

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"