Hi Duane On Tue, Jul 12, 2022 at 09:41:45PM +0000, Wessels, Duane wrote: > >> 3.2. TTLs > > > >> Resolvers MUST cache resolution failures for at least 5 seconds. > >> Resolvers SHOULD employ an exponential backoff algorithm to increase > >> the amount of time for subsequent resolution failures. For example, > >> the initial negative cache TTL is set to 5 seconds. The TTL is > > > > I am guessing the authors meant to write "timeout cache TTL" here > > instead of negative cache TTL. In any case, the phrase "negative cache > > TTL" has a well-understood meaning per RFC 2308, and should not be > > overloaded/reused to indicate timeout cache TTL. > > We didn’t really mean “timeout cache TTL” here. Rather, the intention > is specify requirements for caching all types of resolution failures. > That means SERVFAIL, REFUSED, timeouts, and the others listed in Section 2. > > I think perhaps your point is that RFC 2308 talks about TTLs for negative > *answers* (NXDOMAIN, NODATA) and what we are proposing is different, often > in the absence of an answer. > > Would this rewrite alleviate your concern? > > For example, > the initial TTL for negatively caching a resolution failure is set to > 5 seconds. The TTL is doubled after each retry that results in > another resolution failure. Consistent with [RFC2308], resolution > failures MUST NOT be cached for longer than 5 minutes.
Yes this seems better.
> >> 3.3. Scope
> >
> >> Resolution failures MUST be cached against the specific query tuple
> >> <query name, type, class, server IP address>.
> >
> > Have you considered the effect of caching the timeout against just an
> > upstream server's IP address? I'm not saying you should, but wondering
> > if any of the other tuple fields are relevant to have separate
> > more-specific timeout cache entries.
> >
> > In other words, is it necessary for there to be a distinction among
> > timeouts for:
> >
> > (1) example.org., A, IN, 10.0.0.1
> >
> > (2) example.org., TYPE65, IN, 10.0.0.1
> >
> > (3) example.com., A, IN, 10.0.0.1
> >
> > Traditionally, a resolver's upstream RTTs and timeouts are tracked
> > against the nameserver IP address. A failure to respond has been
> > considered as a property of the NS (implementation) or path to that NS.
> >
> > My colleagues are handling an issue where an authoritative nameserver
> > does not respond to TYPE65 queries, but responds to queries for common
> > query types such as address records. In this case, without mitigating
> > with controls, the resolver is a little stumped and keeps attempting to
> > contact the upstream NS because it receives some responses from it. The
> > queries for which there are no responses eventually end up waiting for
> > the maximum timeout limit because the resolver keeps trying to talk to
> > it. On a busy resolver, these queries consume resources.
> >
> > We could consider the upstream NS as "bad" if it appears to respond to
> > some queries but doesn't respond to others with some response. But
> > one-off or transient timeouts can occur sometimes due to network packet
> > loss.
> >
> > In our case, if the resolver were to block this zone's upstream NSs as
> > bad, it wouldn't be able to respond to any queries within that zone
> > (even address records). It appears to be a popular country-level zone,
> > and it's unlikely the upstream operators will fix it to respond to
> > TYPE65 queries in the short-term. In such cases, a heavy-handed approach
> > may not be practical.
>
> We have not really considered a recommendation to cache against a name
> server’s IP address only. The idea to cache against the 4-tuple comes
> from 2308 (sections 7.1 and 7.2).
>
> We feel that improved caching based on the 4-tuple would be a big win.
> It sounds like perhaps you are suggesting a more aggressive approach might
> encourage authoritative operators to fix their systems?
I suggest considering approaches such as different structures for
caching different types of failure conditions, as these occur at
different layers and caching against different keys may improve their
reuse. In a way, some resolvers already do this.
* Timeouts occur at a different layer and are a property of the
peer/path. So if a peer times out for question A, that information may
be considered for a question B to the same peer.
* A REFUSED RCODE is typically a property of the zone or NS due to its
configuration, such as if the NS is not configured to answer for that
zone, or if the client is not authorized via ACL to query that zone
(or even that NS). So you may choose to consider a previously cached
REFUSED answer for a question within a zone A for all questions into
zone A.
* A SERVFAIL RCODE may occur due to various reasons. For example, a zone
may be configured but may not have been loaded on an authoritative
NS. The NS may be out of resources. An upstream resolver (forwarding)
may be unable to resolve an answer due to a permanent or transient
error (e.g., due to unreachable NS, or failure to resolve NS address
records, or DNSSEC validation failure). Depending on the context, it
may be possible to reuse a previously cached failure result for
questions outside the 4-tuple.
This is to improve reuse.
One more item: A regular resolver cache's negative entries suffer from
random subdomain style attacks for which different NX specific
mitigations are used to improve cache usage. The resilience of an
auxiliary 4-tuple failure cache should be considered along these lines
carefully, as it could be disrupted at a popular public resolver via a
random pattern attack.
Sorry I haven't read the draft carefully.. just quickly skimmed it. :) I
will follow up at a later date.
Mukund
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
