Hi Duane,
On Wed, Jul 5, 2023 at 18:32, Wessels, Duane
<[[email protected]](mailto:On Wed, Jul 5, 2023 at 18:32,
Wessels, Duane <<a href=)> wrote:
> On Jun 30, 2023, at 2:32 PM, Joe Abley <[email protected]> wrote:
>
>> 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.
I like it.
>> 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.
Great!
>> 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.
That seems better to me, thanks.
>> 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
Unless you're going to reuse the phrase "timeout value" somewhere else I'm not
sure why you define it, but that is definitely clearer to me than the original
and I am wary of being even more pedantic than I already was (which is why I
didn't make any comment above about "a given query") (whoops, inside voice).
Thanks for taking care of those things. I think the document is ready to ship.
Joe
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
