Subject: [DNSOP] Last Call: <draft-ietf-dnsop-no-response-issue-14.txt> (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice

From: The IESG <[email-masked]>
Date: Thu, 05 Dec 2019 18:00:39 -0800

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'A Common Operational Problem
in DNS Servers - Failure To Communicate.'
  <draft-ietf-dnsop-no-response-issue-14.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2019-12-19. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   The DNS is a query / response protocol.  Failing to respond to
   queries, or responding incorrectly, causes both immediate operational
   problems and long term problems with protocol development.

   This document identifies a number of common kinds of queries to which
   some servers either fail to respond or else respond incorrectly.
   This document also suggests procedures for zone operators to apply to
   identify and remediate the problem.

   The document does not look at the DNS data itself, just the structure
   of the responses.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ballot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - IETF stream)
    rfc3225: Indicating Resolver Support of DNSSEC (Proposed Standard - IETF stream)
    rfc7766: DNS Transport over TCP - Implementation Requirements (Proposed Standard - IETF stream)
    rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - IETF stream)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Dec 2019 10:39:45 +0100

On Thu, Dec 05, 2019 at 06:00:39PM -0800,
 The IESG <[email-masked]> wrote 

>   <draft-ietf-dnsop-no-response-issue-14.txt> as Best Current Practice

I just tested the dig commands against NSD and Knot. No problem for
NSD but Knot has a discrepancy:

8.1.4 "Testing Unknown Opcodes"

expect: status: NOTIMP

But:

% dig +noedns +noad +opcode=15 +norec +header-only @2001:678:f::1  

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> +noedns +noad +opcode=15 +norec +header-only @2001:678:f::1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: RESERVED15, status: FORMERR, id: 58770
;; flags: qr; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; Query time: 24 msec
;; SERVER: 2001:678:f::1#53(2001:678:f::1)
;; WHEN: Mon Dec 16 10:28:49 CET 2019
;; MSG SIZE  rcvd: 12

Do we agree that Knot is wrong and the draft is right? Or is FORMERR
acceptable?

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 17 Dec 2019 16:27:05 +0100

> Do we agree that Knot is wrong and the draft is right? Or is FORMERR

The discrepancy should disappear eventually:
https://gitlab.labs.nic.cz/knot/knot-dns/commit/2b31ee57a7c

I personally do have occasional issues finding out which RCODE is
appropriate for some error situations.

Thanks
--Vladimir

---

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Dec 2019 20:28:22 -0500

[ Note: CC list edited ]

Hi there authors,

During the IETF LC Stephane supported the document (an important
document, worthy of publication), but noted that:
1: the document only deals with auth servers and that it should be
more explicit and
2: that Section 3 is confusing, and that Matt had provided some text
which helps make this better --
https://mailarchive.ietf.org/arch/msg/dnsop/_Nq8PAVOapIVal2BS7P-jlWmnuc

Having reread section 3 (and Matt's suggestions) I agree with Stephane
on both of these - I also think that addressing these should be quite
easy (I don't think it requires a "restructuring"), especially as Matt
has provided suggested text...
I'd appreciate if you can address these, and SHOUT LOUDLY once you've
had a chance to do so (or let me know how else you'd like to handle
this).

I also think that it would be worth adding an Acknowledgements section...

Thanks,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf