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

[Tim Wicinski <[e-mail]>]

Mark and I sat down and talked about this draft in Berlin, and I have 
some strong concerns about specific sections (3 and 10), but I also love 
large parts of the draft.  I have a (rather) large sheet of edits for 
him that I promised him I would get to him.  I have failed him.  I will 
effort to get these out by the weekend.

tim

(Ed - now you may being mocking)

On 8/18/16 10:34 AM, Edward Lewis wrote:
> ##   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.
>
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>