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

[Tony Finch]

Joe Abley  wrote:
> On 26 Jul 2017, at 13:28, Richard Gibson  wrote:
> >
> > 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).
>
> 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    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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 26 Jul 2017, at 14:50, Richard Gibson  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.

> Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks!
> 
> Ha! I'll use Markdown conventions in the future.

That would be a significant sideprovement.


Joe "text/plain" Abley

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Richard Gibson]

On Wed, Jul 26, 2017 at 2:24 PM, Joe Abley  wrote:

>
> On 26 Jul 2017, at 13:28, Richard Gibson  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  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.

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

Ha! I'll use Markdown conventions in the future.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Joe Abley]

On 26 Jul 2017, at 13:28, Richard Gibson  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 
 was an 
easy-to-find example of trouble in the real world. 

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

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.

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Richard Gibson]

On Tue, Jul 25, 2017 at 4:52 PM, Joe Abley  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
> > 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  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. 

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

[Joe Abley]

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop