Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-caching-resolution-failures-03

[Peter van Dijk <[e-mail]>]

Hello Duane & others,

thank you for your response. Comments inline below.


On Thu, 2023-06-29 at 23:58 +0000, Wessels, Duane wrote:
> 
> 
> > 
> > ## 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"?
> 
> I see your point.  We propose this change to the introduction sentence:
> 
> A name server returns a message with the RCODE field set to REFUSED
> when it refuses to process the query, e.g., for policy or other reasons.

Works for me.

> 
> > 
> > ## 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*.
> 
> For reference, here’s the sentence in question at the start of 3.1:
> 
>    A resolver MUST NOT retry a given query over a server's transport more
>    than twice (i.e., three queries in total) before considering the
>    server's transport unresponsive for that query.
> 
> We feel that “a given query” and “for that query” in the sentence sufficiently limits the
> scope here, and there is no need to qualify it by some amount of time.
> 
> As an example, let’s say that a recursive has been asked to lookup www.example.com (our “given” query).  The example.com zone has two name servers, each of which has two IP addresses, and (presumably) two transports.  It can send 3 queries to 199.43.135.53 over UDP (then that transport is unresponsive), 3 queries to 199.43.133.53 over UDP, same over TCP, over IPv6, and so on.  In total the recursive can send 2x2x2x3 = 24 queries before it has to give up if all servers and all transports are unresponsive. At this point the resolver gives up on that query and returns SERVFAIL.
> 
> Then, section 3.2 is about caching and says that the resolution failure MUST be cached for at least 5 seconds, but otherwise gives implementations a lot of freedom in how to do that.  Could be by query tuple, by server/transport, or some other way.

Right! 3.2 solves this.

> > 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.
> 
> We feel that MUST NOT is appropriate but would like more input from working group
> members and implementors especially.

Ok

> > "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, ..".
> 
> We think “compatible with the resolver’s security policies” goes without saying, but don’t mind making it explicit.

I am inclined to agree, and will leave this for others to judge.

> > 
> > ## 3.2
> > 
> > A previous review
> > (https://secure-web.cisco.com/1-uwEOxF71cZbW0W3ux-QNC1pO0bJjYJvc0KHnZ_wN4Xw3M1XWB_K8diPjdzzV1zzAfZ98vObLHcs-9USjQPtEzxOdqnjHtcYGPxv8yID-fDRYNW8i8BtGJL-qahSS-JHbS3LHL6Bfm0duG-nUUKdSZF_MOoDFhQymCFnu838N4-l8Ky7xjoVKijU3pbZHLVQFpxjYecSLm0hqLoc4GW9n2Ri-vYT-lKiSPl5qB72Q1kbSUp21qnHSMMrfCCEizICDfjVzCKrwtau5DkwfiR7PVxgh2wT1twgX8oVBhJIY-0QfTaJLnHg7itWRgwH3tcX/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fdnsop%2FsJlbyhro-4bDhfGBnXhhD5Htcew%2F)
> > 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.
> 
> The relevant text here currently says:
> 
>    The implementation might cache different resolution failure conditions
>    differently.  For example, DNSSEC validation failures might be cached
>    according to the queried name, class, and type, whereas unresponsive
>    servers might be cached only according to the server's IP address.
> 
> So we provide two examples, although not really phrased as “tuples”.  I guess you’re suggesting to see more options here and talk about them more as tuples?

Yes, I think that would make sense.

> For the documentation suggestion, maybe something like this?: “Developers SHOULD document their implementation choices so that operators know what behaviors to expect when resolution failures are cached.”

Wonderful.

> 
> 
> First, we apologize for not realizing that this and two other “for discussion” questions were not yet resolved.  We plan to remove the first (from the Introduction).
> 
> For the one that was in section 2.6, we propose this updated text and new section 3.4:
> 
> 2.6.  DNSSEC Validation Failures
> 
>    For zones that are signed with DNSSEC, a resolution failure can occur
>    when a security-aware resolver believes it should be able to
>    establish a chain-of-trust for an RRset but is unable to do so,
>    possibly after trying multiple authoritative name servers.  DNSSEC
>    validation failures may be due to signature mismatch, missing DNSKEY
>    RRs, problems with denial-of-existence records, clock skew, or other
>    reasons.
> 
>    Section 4.7 of [RFC4035] already discusses the requirements and
>    reasons for caching validation failures.  Section 3.4 of this
>    document strengthens those requirements.

Good.

> 3.4.  DNSSEC Validation Failures
> 
>    Section 4.7 of [RFC4035] states:
> 
>    To prevent such unnecessary DNS traffic, security-aware resolvers MAY
>    cache data with invalid signatures, with some restrictions.
> 
>    This document updates [RFC4035] with the following, stronger
>    requirement:
> 
>    To prevent such unnecessary DNS traffic, security-aware resolvers
>    MUST cache DNSSEC validation failures, with some restrictions.

Good :)

> And for the one in section 3.3 we propose this:  
> 
> 3.3.  Requerying Delegation Information
> 
>    Section 2.1 of [RFC4697] identifies circumstances in which "every
>    name server in a zone's NS RRSet is unreachable (e.g., during a
>    network outage), unavailable (e.g., the name server process is not
>    running on the server host), or misconfigured (e.g., the name server
>    is not authoritative for the given zone, also known as 'lame')."  It
>    prohibits unnecessary "aggressive requerying" to the parent of a non-
>    responsive zone by sending NS queries.
> 
>    The problem of aggresive requerying to parent zones is not limited to
>    queries of type NS.  This document updates the requirement from
>    section 2.1.1 of [RFC4697] to apply more generally: Upon encountering
>    a zone whose name servers are all non-responsive, a resolver MUST
>    cache the resolution failure.  Furthermore, the resolver MUST limit
>    queries to the non-responsive zone's parent zone (and other ancestor
>    zones) just as it would limit subsequent queries to the non-
>    responsive zone.

Looks great.

Thanks!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/