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

[Matthew Pounsett <[e-mail]>]

On Wed, 10 Apr 2019 at 16:43, 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.

I think I'm missing something here.  If, for example, the TTL of the
ANAME is 1 hour, what mechanism results in caching holding onto a
negative answer for a broken target name for a minimum of 10 hours,
and to 40 days?

>
> 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.

I feel like this is creating an even bigger potential problem.  What
happens when the owner of the ANAME target legitimately wants that
name to go away, but some other zone owner is leaving an ANAME in
place pointing to that now-nonexistent name?  Continuing to serve the
sibling records indefinitely seems like serve-stale gone horribly
wrong.