> On Jun 30, 2023, at 2:32 PM, Joe Abley <[email protected]> wrote: > > > > 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.
Thanks Joe, some responses inline. > > 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. Good catch, we’ve removed the reference to Private Use, Reserved, etc. > > 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". We’re inclined to agree and have removed the phrase as you suggest. > > 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. We’ve made changes to be more consistent when talking about SERVFAIL, REFUSED, and FORMERR responses, using the short all-caps names as you suggest. > > 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. Based on your points here, we suggest this update to section 2.3: 2.3. Timeouts and Unreachable Servers A timeout occurs when a resolver fails to receive any response from a server within a reasonable amount of time. Additionally, a transport layer protocol may more quickly indicate lack of reachability in a way that wouldn't be considered a timeout. For example: an ICMP port unreachable message, a TCP "connection refused" error, or a TLS handshake failure. [RFC2308] refers to these conditions collectively as "dead / unreachable servers." Note that resolver implementations may have two types of timeouts: a smaller timeout which might trigger a query retry and a larger timeout after which the server is considered unresponsive. Section 3.1 discusses the requirements for resolvers when retrying queries. > > 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. We’ve added this: Although the extended DNS errors method exists "primarily to extend SERVFAIL to provide additional information," it "does not change the processing of RCODEs" [RFC8914]. This document operates at the level of resolution failure and does not concern particular causes. > > 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). That is the intention. Is this more verbose text better? A resolver MUST NOT retry a given query to a server address over a given transport protocol more than twice (i.e., three queries in total) before considering the server address unresponsive over that transport for that query. > 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. how about this? This document does not place any requirements on how long an implementation should wait before retrying a query (aka timeout value), which may be implementation- or configuration-dependent. It > > 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." Fixed, thanks. > > 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. Also fixed. DW _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
