[DNSOP] draft-ietf-dnsop-no-response-issue-03

[Edward Lewis <[e-mail]>]

##   A Common Operational Problem in DNS Servers - Failure To Respond.
##                 draft-ietf-dnsop-no-response-issue-03

I have a lot of high-level concerns with this document.

##1.  Introduction
##
##   The DNS [RFC1034], [RFC1035] is a query / response protocol.  Failure
##   to respond to queries or to respond incorrectly causes both immediate
##   operational problems and long term problems with protocol
##   development.

While the latter is true, operationally the DNS is not strictly query -
response.  It's more like "query - if I want to respond".  I was
"enlightened" during a project 10-15 years ago when I realized that some
DNS implementations choose silence when deciding how to respond.

Based on this premise, the prescriptive language in sections 3 and 10
are very problematic in my opinion.

##2.  Common queries kinds that result in non-responses.

This section is not built on data or a document study, making it seem
flimsy, to wit:

##   Some servers fail to respond to ...

This doesn't establish a need to react to the situation.  "Some" might be
one operator's code, etc.

##3.  Remediating

This section steers far from the purpose of defining interoperability of the
protocol.  This section gets too specific regarding the current business
of DNS registration (registry and registrars) for technical needs.  I don't
think this section belongs in an IETF document.

##7.  Response Code Selection
##
##   NOERROR (no data) are the expected response codes.  A server is not
##   supposed to serve a zone which contains unsupported types ([RFC1034])
##   so the only thing left is return if the QNAME exists or not.  NOTIMP

But we have "Handling of Unknown DNS Resource Record (RR) Types" which
contradicts that "not supposed to".  This is the closest I'll come to a "nit."

##10.  IANA Considerations
##
##   IANA / ICANN needs to consider what tests, if any, from above that it
##   should add to the zone maintenance procedures for zones under its
##   control including pre-delegation checks.  Otherwise this document has
##   no actions for IANA.

There is a lot wrong with that paragraph.  (As in, I'm not sure where to
start.)  The IANA functions operator manages according to community defined
processes, there is no internal consideration of what to test.  Further,
only delegations from the root zone are considered, not anything lower in
the tree.  (I.e., most of the issues observed wouldn't be touched.)

This document would be more useful if it clarified the use of RCODEs in the
face of queries described here, in the vein of "Negative Caching of DNS
Queries (DNS NCACHE)".  We lack any document describing the circumstances
in which RCODE values are returned and what the appropriate reaction to them
is.  As the document stands, it is unspecific regarding issues, particularly
the operational scale, and ventures into policy instead of technical
directions regarding operations.

As an afterthought - Perhaps a whitepaper (non-IETF) can be produced to describe testing methodology and results observed would be an avenue to publicize the situation seen here.