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

[Joe Abley <[e-mail]>]

On 26 Jul 2017, at 13:28, Richard Gibson <[e-mail]> 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 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