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

[Richard Gibson <[e-mail]>]

Responses below.

On 4/9/19 16:04, Bob Harold wrote:
> If it gets an authoritative answer saying that there are no address 
> records, then it should respect that answer.  If that is incorrect, 
> then whatever gave that answer is broken or misconfigured and should 
> be fixed.
>
> Perhaps I am missing something.  In what cases can you imagine getting 
> a response with no errors and no records?

Misconfiguration is precisely the case, but quite possibly 
misconfiguration in the zone of /target/ records as opposed to the zone 
containing the ANAME. And there are two problems with respecting that 
[negative] answer.

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.

The second problem is for the query originator and their ANAME-aware 
resolver, which will be forced to resolve the SOA of the 
ANAME-containing zone in order to issue a proper RFC 2308 Type 2 NODATA 
response <https://tools.ietf.org/html/rfc2308#section-2.2.1>—and such 
resolution must take place synchronously, tying up resolver resources 
and increasing end-user latency (insignificantly when the SOA is already 
cached, significantly when it is not).

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.