Subject: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

From: Joe Abley <[email-masked]>
Date: Tue, 25 Jul 2017 16:52:56 -0400

Hi Richard, all,

I foolishly allowed Tim to pay for lunch and therefore have been tricked into doing actual work. There are a couple more of these inbound to the list, one for each of the e-mails containing points that were found not to have been addressed in -04. My goal is to identify some kind of consensus on each this week and the propose some actual text.

With reference to:

  https://mailarchive.ietf.org/arch/msg/dnsop/_W6ois9hFYlAWUmka21FX91910s

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

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.

>    - Insisting that the HINFO OS field SHOULD be empty ("set to the null
>    string") seems a little too strong; there's room in it for—and value
>    from—a short explanation (e.g., as can be observed today:
>    
> dns.cloudflare.com
> . 3789 IN HINFO "Please stop asking for ANY" "See
>    draft-ietf-dnsop-refuse-any"). I'd prefer text like "The OS field
> of the HINFO
>    RDATA SHOULD be short to minimize the size of the response, and MAY be
>    empty or MAY include a summarized description of local policy."

I am happy with that text. Unless there are violent objections from the assembled throng, I will make that change.

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

>    - "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 :-)

Joe

---

From: Richard Gibson <[email-masked]>
Date: Wed, 26 Jul 2017 13:28:22 -0400

On Tue, Jul 25, 2017 at 4:52 PM, Joe Abley <[email-masked]> wrote:

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

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

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

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 <[email-masked]> 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*.*

---

From: Joe Abley <[email-masked]>
Date: Wed, 26 Jul 2017 14:24:50 -0400

On 26 Jul 2017, at 13:28, Richard Gibson <[email-masked]> wrote:

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

We may be imagining different things by "middlebox" -- I think you're thinking of a resolver, whereas I'm thinking more broadly about stateful inspection, firewalls, ALGs, proxies, forwarders, etc. I think there's an entirely reasonable and observable expectation that QTYPE=ANY passthrough works in that broader sense. Mark's <https://www.ietf.org/proceedings/92/slides/slides-92-dnsop-7.pdf> was an easy-to-find example of trouble in the real world. 

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

OK. Your future tense is Cloudflare's past tense and I have not heard of an example of the kind of operational confusion that you're predicting there, but perhaps I'm just not listening in the right dark corners.

I will plan to add text to acknowledge the lack of signalling but not to change the mechanism to introduce any. People should throw rocks if that seems bad.

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

OK, I'm fine with that.

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

Noted.

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

OK. I'll look at this again.

> 1. The draft should standardize on one of "RRSet" (capital S, 17 current instances) or "RRset" (minuscule S, 7 current instances).

Noted. The RFC Editor is well-practiced at dealing with that kind of thing, but it doesn't help to give them less work ahead of time.

> 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):

Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks!

Joe

---

From: Richard Gibson <[email-masked]>
Date: Wed, 26 Jul 2017 14:50:24 -0400

On Wed, Jul 26, 2017 at 2:24 PM, Joe Abley <[email-masked]> wrote:

> 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.
>
> We may be imagining different things by "middlebox" -- I think you're
> thinking of a resolver, whereas I'm thinking more broadly about stateful
> inspection, firewalls, ALGs, proxies, forwarders, etc. I think there's an
> entirely reasonable and observable expectation that QTYPE=ANY passthrough
> works in that broader sense. Mark's <https://www.ietf.org/
> proceedings/92/slides/slides-92-dnsop-7.pdf> was an easy-to-find example
> of trouble in the real world.
>

Yes, color me corrected on vocabulary but unconvinced on interference...
those slides seem to mostly demonstrate noncompliance by name servers
theirselves with respect to EDNS data in queries, whereas the data I'm
suggesting would only appear in responses.

I will plan to add text to acknowledge the lack of signalling but not to
> change the mechanism to introduce any. People should throw rocks if that
> seems bad.

That works. And I'm all out, so you're safe from me.

> bold):

Ha! I'll use Markdown conventions in the future.

---

From: Joe Abley <[email-masked]>
Date: Wed, 26 Jul 2017 15:00:58 -0400

On 26 Jul 2017, at 14:50, Richard Gibson <[email-masked]> wrote:

> Yes, color me corrected on vocabulary but unconvinced on interference... those slides seem to mostly demonstrate noncompliance by name servers theirselves with respect to EDNS data in queries, whereas the data I'm suggesting would only appear in responses.

My recollection was that the machinery Mark was using wouldn't distinguish between problems caused by nameservers and problems introduced by middleware, but it *was* a while ago. Anyway, I'm not arguing so much as trying to explain myself, and...

> That works. And I'm all out, so you're safe from me.

... thanks for that.

> Ha! I'll use Markdown conventions in the future.

That would be a significant sideprovement.

Joe "text/plain" Abley

---

From: Tony Finch <[email-masked]>
Date: Thu, 27 Jul 2017 09:49:10 +0100

Joe Abley <[email-masked]> wrote:
> > without indication of such, and predict that it will hinder
> > operational problem investigation and remediation (especially
> > pertaining to IPv4/IPv6 issues).
>
> OK. Your future tense is Cloudflare's past tense and I have not heard of
> an example of the kind of operational confusion that you're predicting
> there, but perhaps I'm just not listening in the right dark corners.

The only minimal-any confusion I have experienced recently was when the
BIND 9.12 development version of `dig` started using TCP for ANY queries
which made me think minimal-any wasn't working properly :-) But I think
in most cases this change will reduce the confusion Richard is worried
about.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Portland, Plymouth: Westerly 4 or 5, increasing 6 at times in north. Moderate,
occasionally rough in west Plymouth. Showers. Good.