Re: [DNSOP] Working Group Last Call for Negative Caching of DNS Resolution Failures

[Joe Abley <[e-mail]>]

On Jun 21, 2023, at 11:00, Tim Wicinski <[e-mail]> wrote:

> This starts a Working Group Last Call for draft-ietf-dnsop-caching-resolution-failures
>
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-caching-resolution-failures/
>
> The Current Intended Status of this document is: Proposed Standard/Standards Track
>
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out.
> If someone feels the document is *not* ready for publication, please speak out with your reasons.
>
> This starts a two week Working Group Last Call process, and ends on: 5 July 2023

I have read -04. i like it. I think it's useful and sensible and it should be published. Whether this particular rev is ready for publication I would say depends on whether the authors disagree with all the pedantic nonsense that follows. They should feel free not to agree.

There are some nits that the authors might want to address or prepare to be outraged at the suggestion of.

The last paragraph in section 1.3 defines terms that are not used in this document except in that paragraph, I think? Perhaps they are vestigial.

In section 2.1 the phrase "Authoritative servers, and more specifically secondary servers, return server failure responses when they don't have any valid date for a zone." I don't think secondary servers are special from the perspective of a client sending a query; such clients cannot usually distinguish between primary and secondary servers and there are a wealth of well-used authoritative servers deployed that don't use zone transfers anyway. I suggest removing the qualifying "and more specifically secondary servers".

In section 2.1 the phrase "server failure responses" is used in place of SERVFAIL. In section 2.2 return codes are referred to as RCODEs and REFUSED is used in place of "refused return codes" or something. I don't think it matters too much which is used, but it seems like the document should be consistent. I like the all-caps representations, personally, but if you go with that there's an argument that they should be defined, e.g. by means of a reference to whatever the latest dns-terminology draft is in section 1.3.

I wonder whether another subsection of section 2 would be useful to discuss transactions that don't time out, but whose transports return positive indications of failure, e.g. a TCP handshake failure or RST, or a TLS negotiation failure when using DoT or DoH. These are not timeouts, but they also lack RCODEs (since they lack responses). Is it worth suggesting that failures that are transport-specific be cached, e.g. to record that server 192.0.2.1 doesn't respond on TCP so don't bother bombarding it with SYNs? You talk about this in 3.1; perhaps a forward reference from section 2 would be helpful.

Section 2 talks at some length about RCODEs like SERVFAIL and REFUSED but is silent on the existence of the extended error option. This may be ok, e.g. since the EDE spec is quick to specify that it "does not change the processing of RCODEs" and since the purpose of your draft is presumably to deal with retry behaviour regardless of whether EDE is supported, but it feels odd not to mention it at all even if it's just to clarify why it's ok for this specification to deal just with RCODEs.

Section 3.1 uses the phrase "a server's transport". I stared at that for quite a bit and I'm not sure I know for sure what it means. I think you're talking about the number of successive transmission of the same query using the same transport that are sent to the same server address. Perhaps that's obvious to other people (or perhaps my interpretation illustrates that there is some ambiguity). Later in this section when you say "timeout value" I think you're talking about how long to wait before identifying a timeout. Again, perhaps that's obvious.

I think the lack of prescriptive direction in section 3.2 concerning precisely how software should implement the required caching is very sensible.

I like the broadening of RFC 4697's advice in section 3.3. I think that's a mistake in 4697. It's good to correct it.

I think the update to RFC 4035 in section 3.4 is similarly sensible.

The recommended sentence for Section 4 according to RFC 8126 is "This document has no IANA actions."

Section 8 contains the sensible instruction "remove [...] before publication". Section 9's instruction is "remove [...] upon publication". I do not know what that means. Hopefully the RFC editor does.

I had forgotten about draft-muks-dnsop-dns-thundering-herd. It's a shame that has expired. If the authors need a volunteer to help bring it back to life, I could help, but it looks pretty good as-is to me. Perhaps it just needs a a poll for adoption?

Joe