Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-03

["Wessels, Duane" <[e-mail]>]

Hi Peter,

Thank you for the detailed review.  Responses from the authors are inline below.



> On Jun 26, 2023, at 7:47 AM, Peter van Dijk via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Peter van Dijk
> Review result: Almost Ready
> 
> I have been selected as the DNS Directorate reviewer for this draft. The
> DNS Directorate seeks to review all DNS or DNS-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the ADs.
> For more information about the DNS Directorate, please see
> https://secure-web.cisco.com/1C33i4Dh-oRD64xG7a2vNsTYqSkPmK_TtaZK5jIi1iKC1wcUTEdFfOLVw2n8nSUfJfqkbodz3_NdwV50FyoYhfQgSizKNv3M_ep9Yx9lkNt6oLgHQ4Vzp63kYnLezQGHdj0sornqx_SXzMbvj1BAzh7zPtyqF42myyeJXxiCyrr6e3QAdSUEYSAtaWewUcT8nEODhdq9BzBue8j3jhmGSCvOkEqY7Y8Tgfwi52mCcXFC6XNOjWYytI5iJuWrXd6WvjALuITYr8tv11C5mJVNaMj6-jLCgBzJbwJt0tkCxrL4MjxM4GuoUUvZ29P9i3K07/https%3A%2F%2Fwiki.ietf.org%2Fen%2Fgroup%2Fdnsdir
> 
> This document is generally in good shape. It is not too prescriptive, leaving
> room to implementers to honour the requirements in a way that makes sense for
> their implementations. The document has not seen a lot of WG discussion; I hope
> this means people have read it and generally agree.
> 
> Section 3.3 contains a "FOR DISCUSSION" note. I believe this means the document
> cannot currently pass Last Call. (See below for some notes on that discussion
> item.)
> 
> I have various nits and suggestions. Please see them below. Section numbers are
> for -03.
> 
> ## 2
> 
> I know section 2 is not meant to be exhaustive, but I wonder if FORMERR
> deserves a mention. In theory, a FORMERR response will not improve with time
> until an auth operator actively intervenes (by updating/replacing software to a
> more compliant version). SERVFAILs, by comparison, can be much more transient.

Good suggestion, we’ve added a short section on FORMERR.

> 
> ## 2.1
> 
> current:
> 
>> Authoritative servers, and more specifically secondary servers,
>> return server failure responses when they don't have any valid data
>> for a zone.  That is, a secondary server has been configured to serve
>> a particular zone, but is unable to retrieve or refresh the zone data
>> from the primary server.
> 
> proposed:
> 
>> Authoritative servers, and more specifically secondary servers,
>> return server failure responses when they don't have any valid data
>> for a query.  For example, a secondary server has been configured to serve
>> a particular zone, but is unable to retrieve or refresh the zone data
>> from the primary server.

Yes, thanks.

> 
> ## 2.2
> 
> The first paragraph correctly mentions "policy reasons". The second paragraph
> correctly says "they are not authoritative". I am not sure not being
> authoritative can be considered a policy reason, so perhaps these two
> paragraphs can be connected with an "or"?

I see your point.  We propose this change to the introduction sentence:

A name server returns a message with the RCODE field set to REFUSED
when it refuses to process the query, e.g., for policy or other reasons.


> 
> ## 2.3
> 
> "If, however, the implementation does not join outstanding queries together,
> ..." - this could use a reference to 5452 4.3 and 5452 5, pointing out that
> implementations really should be joining queries together for security reasons
> whenever they can, beside the reason given in the draft of not overloading
> authoritatives.

Added.

> 
> ## 3.1
> 
> "A resolver MUST NOT retry a given query over a server's transport  more than
> twice" - should this be clarified to say "in a short period of time" or
> something like that? Clearly a retry is allowed *eventually*.

For reference, here’s the sentence in question at the start of 3.1:

   A resolver MUST NOT retry a given query over a server's transport more
   than twice (i.e., three queries in total) before considering the
   server's transport unresponsive for that query.

We feel that “a given query” and “for that query” in the sentence sufficiently limits the
scope here, and there is no need to qualify it by some amount of time.

As an example, let’s say that a recursive has been asked to lookup www.example.com (our “given” query).  The example.com zone has two name servers, each of which has two IP addresses, and (presumably) two transports.  It can send 3 queries to 199.43.135.53 over UDP (then that transport is unresponsive), 3 queries to 199.43.133.53 over UDP, same over TCP, over IPv6, and so on.  In total the recursive can send 2x2x2x3 = 24 queries before it has to give up if all servers and all transports are unresponsive. At this point the resolver gives up on that query and returns SERVFAIL.

Then, section 3.2 is about caching and says that the resolution failure MUST be cached for at least 5 seconds, but otherwise gives implementations a lot of freedom in how to do that.  Could be by query tuple, by server/transport, or some other way.




> 
> Also, "MUST NOT" is pretty strong language. Given the various process models of
> resolver implementations, two subprocesses (threads) both retrying the same or
> a similar thing a few times can not always be avoided. Would you settle for
> SHOULD NOT? The "given" in "retry a given query" gives some leeway, but not
> enough, I feel.

We feel that MUST NOT is appropriate but would like more input from working group
members and implementors especially.


> 
> "may retry a given query over a different transport .. believe .. is available"
> - this ignores that some transports have better security properties than
> others. One currently active draft in this area is
> draft-ietf-dprive-unilateral-probing. Perhaps add some wording, without being
> too prescriptive, such as "available, and compatible with the resolver's
> security policies, ..".

We think “compatible with the resolver’s security policies” goes without saying, but don’t mind making it explicit.


> 
> ## 3.2
> 
> A previous review
> (https://secure-web.cisco.com/1-uwEOxF71cZbW0W3ux-QNC1pO0bJjYJvc0KHnZ_wN4Xw3M1XWB_K8diPjdzzV1zzAfZ98vObLHcs-9USjQPtEzxOdqnjHtcYGPxv8yID-fDRYNW8i8BtGJL-qahSS-JHbS3LHL6Bfm0duG-nUUKdSZF_MOoDFhQymCFnu838N4-l8Ky7xjoVKijU3pbZHLVQFpxjYecSLm0hqLoc4GW9n2Ri-vYT-lKiSPl5qB72Q1kbSUp21qnHSMMrfCCEizICDfjVzCKrwtau5DkwfiR7PVxgh2wT1twgX8oVBhJIY-0QfTaJLnHg7itWRgwH3tcX/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2FsJlbyhro-4bDhfGBnXhhD5Htcew%2F)
> suggested that the then-chosen tuple was not specific enough, and also said it
> was too prescriptive. I agree with both. The current draft prescribes nothing,
> which I'm generally a fan of!
> 
> However, speaking to a coworker (the one likely responsible for implementing
> this draft, if it turns out our implementation deviates from its final form)
> told me "some guidance would be nice". After some discussion on
> prescriptiveness, here is our suggestion: do not prescribe, but mention
> (without wanting to be complete) a few tuple formats that might make sense, and
> suggest that implementations document what they choose here.

The relevant text here currently says:

   The implementation might cache different resolution failure conditions
   differently.  For example, DNSSEC validation failures might be cached
   according to the queried name, class, and type, whereas unresponsive
   servers might be cached only according to the server's IP address.

So we provide two examples, although not really phrased as “tuples”.  I guess you’re suggesting to see more options here and talk about them more as tuples?

For the documentation suggestion, maybe something like this?: “Developers SHOULD document their implementation choices so that operators know what behaviors to expect when resolution failures are cached.”

> 
> ## 3.3
> 
>> FOR DISCUSSION: the requirement quoted above may be problematic
>> today.  e.g., focusing on NS as the query type (a) probably goes
>> against qname minimization, and (b) is not the real problem.  Also
>> RFC 4697 doesn't place any time restriction (TTL) on this.
> 
> *Before* qname minimization, queries that yield delegation answers often did
> not have type NS. With qname minimization, depending on the implementation,
> those queries might in fact be NS. (7816 specifies NS; 9156 relaxes the qtype
> requirement for qname-minimized queries). That said, there is no reason for the
> requery (which, as this draft reiterates, MUST NOT be done) to use NS, and so,
> I do agree the focus on the NS type should be removed.
> 
> As for TTL, the originally received delegation will eventually expire, so the
> requery will in fact happen at some time after that expiry.

First, we apologize for not realizing that this and two other “for discussion” questions were not yet resolved.  We plan to remove the first (from the Introduction).

For the one that was in section 2.6, we propose this updated text and new section 3.4:

2.6.  DNSSEC Validation Failures

   For zones that are signed with DNSSEC, a resolution failure can occur
   when a security-aware resolver believes it should be able to
   establish a chain-of-trust for an RRset but is unable to do so,
   possibly after trying multiple authoritative name servers.  DNSSEC
   validation failures may be due to signature mismatch, missing DNSKEY
   RRs, problems with denial-of-existence records, clock skew, or other
   reasons.

   Section 4.7 of [RFC4035] already discusses the requirements and
   reasons for caching validation failures.  Section 3.4 of this
   document strengthens those requirements.

3.4.  DNSSEC Validation Failures

   Section 4.7 of [RFC4035] states:

   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
   cache data with invalid signatures, with some restrictions.

   This document updates [RFC4035] with the following, stronger
   requirement:

   To prevent such unnecessary DNS traffic, security-aware resolvers
   MUST cache DNSSEC validation failures, with some restrictions.



And for the one in section 3.3 we propose this:  

3.3.  Requerying Delegation Information

   Section 2.1 of [RFC4697] identifies circumstances in which "every
   name server in a zone's NS RRSet is unreachable (e.g., during a
   network outage), unavailable (e.g., the name server process is not
   running on the server host), or misconfigured (e.g., the name server
   is not authoritative for the given zone, also known as 'lame')."  It
   prohibits unnecessary "aggressive requerying" to the parent of a non-
   responsive zone by sending NS queries.

   The problem of aggresive requerying to parent zones is not limited to
   queries of type NS.  This document updates the requirement from
   section 2.1.1 of [RFC4697] to apply more generally: Upon encountering
   a zone whose name servers are all non-responsive, a resolver MUST
   cache the resolution failure.  Furthermore, the resolver MUST limit
   queries to the non-responsive zone's parent zone (and other ancestor
   zones) just as it would limit subsequent queries to the non-
   responsive zone.


DW