On 11 Apr 2019, at 23:45, Matthew Pounsett <m...@conundrum.com> wrote:
> On Thu, 11 Apr 2019 at 20:02, Richard Gibson > <richard.j.gib...@oracle.com> wrote: >> >> The first problem is for the owner of the ANAME-containing zone, for whom >> the upstream misconfiguration will result in downtime and be extended by >> caching to the MINIMUM value from their SOA, which in many cases will be one >> to three orders of magnitude greater than the TTL of the ANAME itself. > > [snip] > >> But this suffers from both of the problems I have been complaining about—the >> resolver does not necessarily have the zone SOA, possibility necessitating >> an inline lookup, and per RFC 2308 the negative response will be cached >> according to values from the SOA that are unrelated to and far exceed the >> TTL of the ANAME. > > Ah, I see the confusion. You're using definitive statements such as > "will" when what you actually mean is "may." There's no specific > mechanism that causes the client to cache the negative response "for > one to three orders of magnitude greater than the TTL of the ANAME." > And, the TTL of the SOA doesn't necessarily "far exceed" the TTL of > the ANAME. You're just presupposing that will be a common > configuration? You can't tell how long to cache a negative answer for unless you know data from closest-enclosing SOA RRSet (the RRSet TTL and the SOA.MINIMUM field). In this case potentially there are two SOA RRSets to consider, the one enclosing the ANAME and the one enclosing the ANAME target, and there's the additional complication that the ANAME RR also has a TTL. I don't see text in the working draft (the one on github) that makes the expected behaviour clear in the case that Richard outlined. I think it makes sense to specify this carefully, otherwise there is a risk of negative answers being cached for longer than expected, which might be especially bad in the case (perhaps the expected use case) where availability and deterministic cache behaviour are kind of important. I have not been following this closely enough, quite possibly. Joe
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
