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

[Bob Harold <[e-mail]>]

On Wed, Apr 10, 2019 at 4:42 PM Richard Gibson <[e-mail]>
wrote:

> 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.
>
Fair enough.  I would rather solve the long MINIMUM problem in general,
rather than only for this specific case.  But here was have a fairly easy
source of backup answers, so it will be easier than a general solution.  I
don't like it, but I see your point.

As for when we might want an NXDOMAIN answer, perhaps:
CDN is overwhelmed or web servers are all down, so stop users from trying
to connect.
Or server changes and we don't want users to fall back to old, incorrect
addresses.

-- 
Bob Harold