[This is about draft-ietf-dnsop-respsize-15] IMHO, the draft is not ready to be published. Details:
I believe it is important to have such a document on the consequences of the DNS response size. I congratulate the initial authors and the recent resurrector. The document is a thorough analysis of the intricacies of DNS responses. However, in its current form, there are two issues, an inconsistent terminology, and a pessimistic tone which do not seem fully backed by the facts. The biggest issue comes from the many misuses of the word "truncation". Unlike many DNS concepts, where there is no standard vocabulary and huge variation between RFCs, "truncation" is well defined (RFC 2181, section 9, since RFC 1035 was much more sloppy). Truncation == TC bit set == an incomplete RRset was included. But the draft often uses truncation in a much broader meaning, something like "I would have wanted to include more data", meaning which is explicitely excluded by RFC 2181. OMISSION OF DATA IS NOT TRUNCATION and this draft keeps forgetting that. Examples: Section 3.1 "Note that truncation of the additional data section might not be signaled via the TC bit since additional data is often optional" which is false (if the TC bit is not set, there is no truncation, per definition; if there is an incomplete RRset even in the additional section, TC bit MUST be set). Section 3.2 "The best case is no truncation at all. This is because many requesters will retry using TCP immediately, or will automatically requery for RRSets that are possibly truncated, without considering whether the omitted data was actually necessary." It is not false but it seems to imply that omission of some data is the same thing as truncation. Section 3.3 "If any "necessary" content cannot be fit in the response, then it is advisable that the TC bit be set" This directly contradicts RFC 2181, section 9. Note also that "required" and "necessary" are used in the draft but never defined. In a referral, the only RRset (for non-DNSSEC answers) which is really required is the NS set. Glue records are not required (you can always make a specific request for them: it means one more RTT but it will work). Section 3.3 is very ambiguous here, in its second paragraph. My suggestions for fixing this would be: 1) A clear reminder of the definition of truncation, stating that truncation == TC bit set, and truncation /= omission of data. 2) A definition of "required". Something like: "data is required if its absence would stop the name resolution process". For instance, including the IP addresses of name servers is an optimization, it is not required, even if the name servers are in-zone. 3) Modify the draft to use "truncation" only when it fits. Use "omission of data" for the rest. Second issue, the pessimistic tone. The draft could be read as a warning that horrible things will happen if the size of the answer is not kept well below 512 bytes. But, since the version -00 has been published, typical response sizes have increased and nothing happened. The respsize.pl tool flags .com as always red, for maximum size queries. But we observe daily that .com works. Technical: I've reviewed the tool respsize.pl, both by checking its source code and by running it against many different zones and it seems flawless. The actual quantitative analysis of DNS sizes (this tool, and section 3) is the best part of the draft and a good reason to continue the work on it. Editorial: Abstract: "With a mandated default minimum maximum UDP message size of 512 octets" The concept of minimum maximum is not clear. Section 3.2 : "Anycast [RFC3258] [RFC4786] is a useful technique for improving performance and below the zone cut being described by a delegation is responses." My parser crashed here.
signature.asc
Description: Digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
