Hi dnsop, Tim has asked me for a review for TLD perspective, so here it is.
A. The text in the RFC is very dense and very hard to read for me. Sometimes it feels like that the paragraphs are composed just of bullet points put together. I feel it needs a serious rewrite to improve readability. B. Chapter 3 is missing RFC references at many places C. While reading Chapter 3 I got very confused about intended audience of the I-D. Is is a DNS servers vendors (as in DNS servers), a DNS resolver vendors (as in DNS clients), a DNS protocol compliance testers? D. Section 3.2.1 phrase "the first and last queries" is used at several places in the Chapter 3, but without definition what the first and last query is or should be. It becomes slightly clearer in the Chapter 4, but still it got me _very_ confused. E. Each section in Chapter 3 is written in different style. One time it speaks about misbehavior, second time it speak about correct behavior and f.e. third time it speaks about "Servers should be checked". This is probably relevant to my point 3. I feel that whole Chapter 3 needs to be rewritten using a language that in each Section f.e. defines correct behavior (with references to relevant RFCs), then usual mistakes and then it defines the tests for correct/incorrect behavior. (Or split the Chapter 3 to several chapters each focusing on one of the parts - correct / incorrect / testing). As an example, let's take Chapter 3.2.4 EDNS Flags and rewrite it this way: --cut here-- 3.2.4. EDNS Flags 3.2.4.1 Compliant behaviour DNS server MUST respond to DNS queries with EDNS flags set. Servers SHOULD (or should?) ignore EDNS flags they do not understand and SHOULD NOT (or should not?) add them to the response [RFC6891]. 3.2.4.2 Common mistakes When receiving DNS queries with EDNS flags set, the non-compliant DNS servers: * drop the query (fail to respond) * respond with RCODE indicating failure (FORMERR/SERVFAIL/REFUSED/...) * lorem ipsum, ... 3.2.4.3 Testing DNS Testing Tools wishing to test DNS queries with EDNS flags set SHOULD do <foo> and <bar>. --cut here-- F. Chapter 4 is very long and I feel it has to be split into subsections with recommendations for each relevant party (auth DNS, recursive DNS, DNS operators, TLDs) G. Here comes my greatest objection to the document so far. I don't think that IETF technical community is the right place to give non-technical operational advice to the TLD operators. The paragraph that requires to remove the delegation of the customer zone has a legal implications, and I am sorry to say that but dnsop is not the here to define the legal aspects of the operating a TLD. Such advices must be removed before any form of this document is published. Same goes with other advices that uses language as "it needs to be performed" and similar. There might be some contractual obligations for some types of TLD (gTLDs, new gTLDs, sTLDs) and not for others (ccTLDs). The document might provide a guidance and advices, but it certainly cannot require TLDs to do <random> stuff. While many TLDs have a good relationships with the registrars and DNS operators withing their bailiwick and they work very hard to ensure the DNS service withing the TLD is in overall good health, it's definitely not possible to cut off non-compliant servers from within the TLD authority. On the other hand I definitely have no problem to start failing some horrendous DNS servers if the DNS vendor community agrees to do so, but it would require a responsible and coordinated approach between DNS server vendors (OSS and non-OSS). But pushing this down the TLDs' throats is not a way to make a progress. H. Could the authors use RFC 2119 language in the document? It's quite confusing without it and that becomes especially visible in Chapter 5 where the authors speak about what Firewalls and Load Balancers should and should not do. I. It seems to me that Chapter 5 just repeats what has been already said. A reference to well-structured Chapter 3 (e.g. correct behavior) and saying that it applies to Firewalls and Load Balancers should be sufficient. There's no reason to make a second comprehensive list with the things that have been already stated. Also saying "Nameservers hasve always been expected to be able to hadnel such queries" three times seems to be more fit for a rant than an Internet Standard. J. Chapter 4, 5, 6 and 7 target specific services, so it' very confusing that Chapter 8 jumps back to a definition of what the correct/incorrect DNS behavior is. I think that Chapter 8 needs to be merged with improved Chapter 3. K. Chapter 9 testing should be rewritten to not used BIND's dig, but to provide a detailed definition of DNS queries and responses. Relying on specific tool might be problematic for the future implementors. Providing a description how to construct a testing packet is more universal and less prone to the tool changes in the future. This would also allow to describe and construct tests that are not (yet) implemented in BIND's dig tool. L. Overall I have a feeling this might be an excellent document that would provide a lot of benefit to the DNS community and I support moving this forward. It needs to be extensively rewritten to improve readability and structure of the document. To be really useful, the implementors of DNS protocol should be able to use this as an easy to understand and follow checklist that needs to be followed step by step to get a compliant DNS implementation. The well-informed end-users could then use this document as a bashing instrument when slapping and shaming the various networking equipment vendors from tiny (SOHO) to huge (scrubbing, load-balancing, etc.). Nits: a. (nit) Chapter 2, first paragraph; s/known issues know/knows issues now/ b. (nit) Chapter 3.1.5: s/attempts, they should/attempts should/ Cheers, -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.cz https://nic.cz/ -------------------------------------------- ----- Original Message ----- > From: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > Cc: dnsop@ietf.org > Sent: Monday, 19 September, 2016 01:42:41 > Subject: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-05.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : A Common Operational Problem in DNS Servers - > Failure To > Respond. > Author : M. Andrews > Filename : draft-ietf-dnsop-no-response-issue-05.txt > Pages : 20 > Date : 2016-09-18 > > Abstract: > The DNS is a query / response protocol. Failure to respond or to > respond correctly to queries causes both immediate operational > problems and long term problems with protocol development. > > This document identifies a number of common kinds of queries which > some servers either fail to respond or else respond incorrectly. > This document also suggests procedures for TLD and other zone > operators to apply to help reduce / eliminate the problem. > > The document does not look at the DNS data itself, just the structure > of the responses. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
