Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Matthew Pounsett <[e-mail]>]

On Thu, 11 Apr 2019 at 20:02, Richard Gibson
<[e-mail]> 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?

I think we're still talking about misconfigurations here, and
designing a protocol around people who misconfigure their DNS at the
expense of people who configure it properly seems like a bad path to
take.

> Both of these problems can be addressed by allowing/recommending/requiring ANAME-aware servers to preserve ANAME siblings when resolution of ANAME targets results in NXDOMAIN or NODATA responses, rather than replacing them with an empty RRSet... which, to be honest, seems to be always-undesirable behavior anyway—if anyone can think of a scenario where it would be beneficial to dynamically remove ANAME siblings, please share it.

Yes, I can think of a case where it would be beneficial to remove
ANAME siblings: when the target of the ANAME is removed from the DNS.

> In such a configuration, the owner of the ANAME will be able to see that clients are using its static sibling records rather than its target (and therefore that they are getting no benefit from the ANAME), and can react accordingly. If your concern is excess queries for the ANAME target, then this seems no different from e.g. CNAME—the owner of the target can issue long-lived negative responses while performing whatever other exploration and/or mitigation they deem fit.

If the target of the ANAME disappears, the owner of the ANAME will
similarly be able to recognize the problem and deal with it.  If the
administrator of the name owning the ANAME is concerned about downtime
due to misconfigurations by the target, then that administrator can
either select a different target (presumably by selecting a different
service provider) or set their TTLs appropriately to not be subject to
the potential issue you identified above.

However, if the spec requires preserving the target in the DNS despite
the administrator of the target zone removing it, then that is a path
for abuse by the administrator of the zone containing the ANAME, and
the owner of the target will have no recourse.  This is what I meant
by my reference to serve-stale.