On Tue, Jul 25, 2017 at 4:52 PM, Joe Abley <jabley@hopcount.ca> wrote:

> >    - There is no mechanism for signaling section 4.1/ section 4.3
> "partial
> >    response" behavior to clients (e.g., a new OPT record EDNS header flag
> >    bit
> >    <http://www.iana.org/assignments/dns-parameters/
> dns-parameters.xhtml#dns-parameters-13>
> >    ).
>
> Correct. I presume you are suggesting that there should be one. I have not
> heard anybody else require such a thing, and new EDNS code points are
> thought by at least some to be thorny things to pass undigested through
> middleboxes so I think it's a non-trivial suggestion that would require a
> proposal that itself would need thorough review. That feels out of scope
> for this document, but perhaps something analogous to extended RCODEs in
> the sense that it's channel metadata.
>

The need for such a signal also came up recently in
https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05#section-10
. But in this case particularly, middleboxes should be a complete
non-issue... anyone expecting QTYPE=ANY passthrough is already asking for
trouble.

I think it would be uncontroversial to note explicitly that the mechanism
> described in this document contains no such signalling, however. Let me
> know if that seems like a pragmatic solution.
>

I remain concerned about issuing incomplete responses to ANY queries
without indication of such, and predict that it will hinder operational
problem investigation and remediation (especially pertaining to IPv4/IPv6
issues). My preference has not changed, but an explicit acknowledgment of
the gap at least provides a reference for future improvement.

>    - "Conventional [ANY] response" is used but not defined.
>
> I am not sure why it's ambiguous without a definition. To me that phrase
> seems pretty straightforward; if your core objection is that the DNS
> standards are not written down with great accuracy, yeah. The only
> definition I can think of really is something like "A response to a query
> that had QTYPE=ANY which follows convention" which just seems longer, not
> more clear. What did you have in mind?
>

How about updating document text to replace "conventional ANY queries"
(section 3) and "conventional response" (section 4.1) with "conventional
ANY response" and defining it in the Terminology section:

In this document, "conventional ANY response" refers to an ANY Response
that would be produced by the algorithm in section 4.3.2 of RFC 1034.
Conventional ANY responses can include include records from an arbitrarily
high number of RRSets, up to message truncation.

Also, it therefore appears that this draft needs to be noted as updating
RFC 1034.

>    - "ANY does not mean ALL" is misleading—RFC 1035
> >    <
> > https://tools.ietf.org/html/rfc1035#section-3.2.3>
> >  is clear about
> >    QTYPE=255 being "a request for *all* records" (emphasis mine). That
> >    said, the proposed *response* behavior is consistent with that RFC.
>
> All records that the server constructing the response knows about?
>
> All records that the server can fit into the response given the
> constraints of the available transport?
>
> ALL THE RECORDS IN THE WHOLE WORLD! That was an obscure reference to
> Blackadder the Second that probably pleases nobody but me. ("Kill Bob!"
> "Never!")
>
> I think to that point we can implicitly acknowledge between ourselves that
> less ambiguity would be nice, but that on the whole this text as-is at
> worst does no harm, and at best helps illustrate the philosophy of the
> approach being described.
>
> Let me know how much of that you can live with :-)
>

In light of the above, referencing RFC 1035 actually seems misleading...
the relevant definitions come from RFC 1034, and this draft is consistent
with it in acknowledging use of QTYPE=255 for *requesting* records of all
types, but inconsistent with it in specifying *responses* that
intentionally omit matching records.

On Tue, Jul 25, 2017 at 4:53 PM, Joe Abley <jabley@hopcount.ca> wrote:

> >    1.  A DNS responder can choose to select one or subset of RRSets at
> >        the QNAME.
> >
> >   'one or subset of RRSets' sounds a bit awkward to me
>
> I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset"
> seems wrong, actually; since some vestigial fragment of a set theory
> lecture in the depths of my pre-history is telling me that the empty set is
> always a valid subset.


Suggestion: "A DNS responder can choose to select one or more
nonempty matching RRSets". This works because existence is guaranteed by
the preceding text ("for names that exists that are used", probably better
phrased as "for QNAMEs with at least one nonempty RRSet"). And it has the
added benefit of correctly covering wildcard behavior.

I also discovered some incidental issues while confirming the above:
1. The draft should standardize on one of "RRSet" (capital S, 17 current
instances) or "RRset" (minuscule S, 7 current instances).
2. Section 4.1 appears to have some errors in grammar and use RFC 2119
terms, and should be reworded (removals in strikethrough, additions in
*bold*):

A DNS responder which receives an ANY query MAY decline to provide a
conventional response, or MAY instead send a response with a single RRSet *one
or more selected RRSets* in the answer section.

The RRSet *or RRSets* returned in the answer section of the response MAY be
a single RRSet *MUST be* owned by the name specified in the QNAME. Where
multiple RRSets exist, the responder SHOULD choose a small one(s) *make
selections that minimize response size* to reduce its amplification
potential.


If the zone is signed*, covering* RRSIG records MUST be included in the
answer*.*