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

[Ballot comment]
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"

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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..."

[Ballot 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.

[Ballot comment]
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?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dnsop-refuse-any-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Resource Record (RR) TYPEs registry on the Domain Name System (DNS) Parameters registry page located at:

https://www.iana.org/assignments/dns-parameters/

the existing entry for:

Type: *
Value: 255

is to be changed by having [ RFC-to-be ] added to the references as follows:

+------+-------+-------------------------------+--------------------+
| Type | Value | Meaning | Reference |
+------+-------+-------------------------------+--------------------+
| * | 255 | A request for some or all | [RFC1035][RFC6895] |
| | | records the server has | [This Document] |
| | | available | |
+------+-------+-------------------------------+--------------------+

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-09-04):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, draft-ietf-dnsop-refuse-any@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski , warren@kumari.net
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Providing Minimal-Sized
Responses to DNS Queries that have QTYPE=ANY'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
  The operator of an authoritative DNS server might choose not to
  respond to such queries for reasons of local policy, motivated by
  security, performance or other reasons.

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

  This document updates RFC 1034 and RFC 1035.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ballot/


No IPR declarations have been submitted directly on this I-D.

refuse-any

(1) This documet is being presented as a Proposed Standard. It is
stated in the title page and it is the proper type of RFC.

(2)

Technical Summary:

    The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
    The operator of an authoritative DNS server might choose not to
    respond to such queries for reasons of local policy, motivated by
    security, performance or other reasons. This document provides
    specific behaviorial guidance for DNS servers and/or clients.


Working Group Summary

    There was some initial issues reaching consensus during WGLC, but
    the authors worked out the specific issues with the working group
    and the final version met with strong consensus.

Document Quality


    Document has been well written and edited.  There are current
    implementaions that help drive consensus.

Personnel

    Document Shepherd is Tim Wicinski and Area Director is Warren
    Kumari.

(3)  The document shepherd did several thorough reviews of this
document, both for content as well as editing issues.

(4) The document shepherd is more than satisfied with the depth and
breath of the reviews.

(5) It is the opinion of the document shepherd that this document does
not need broader reviews.

(6) The document shepherd has no specific concerns or issues with this
document.

(7) The authors have confirmed that there are no IPR disclosures that
need to be filed.

(8) No IPR disclosures have been filed for this document.

(9) WG Consensus is solid.

(10) There has been no threats to appeal or discontent.

(11)

    -- The draft header indicates that this document updates RFC1034,
    but the abstract doesn't seem to mention this, which it should.

    -- The draft header indicates that this document updates RFC1035,
    but the abstract doesn't seem to mention this, which it should.


    Found 'SHOULD not' in this paragraph:
   
    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.


(12) Document does not meet any required formal review criteria.

(13)  All references have been identified as either normative or
informative.

(14) There are not normative references that are holding up this
document.

(15) There are no downward normative references in this document.

(16) This document will update RFC 1034 and RFC 1035.  These RFCs are
listed int the title page, discussed in the introduction. These RFCs
are not mentioned in the abstract.

(17) The IANA considerations section requests an update to the Resource
Record (RR) Types Registry to reference this document for one value.
This is consistent with the body of the document.

(18) There are no new IANA registries.