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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
