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

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


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/

 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

Reply via email to