Last Call Review of draft-ietf-dnsop-caching-resolution-failures-03
review-ietf-dnsop-caching-resolution-failures-03-dnsdir-lc-van-dijk-2023-06-26-00

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://wiki.ietf.org/en/group/dnsdir

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.

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

## 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"?

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

## 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*.

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.

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

## 3.2

A previous review
(https://mailarchive.ietf.org/arch/msg/dnsop/sJlbyhro-4bDhfGBnXhhD5Htcew/)
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.

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