On Jun 21, 2023, at 11:00, Tim Wicinski <[email protected]> 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
