On 26 Jul 2017, at 13:28, Richard Gibson <[email protected]> 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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
