On Wed, 10 Apr 2019 at 16:43, 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.
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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
