[DNSOP] Corner-case in DNS authority guidance impacting IPv6-only resolvers

[Erik Nygren <[e-mail]>]

In chasing down some problems between some IPv6-only DNS resolvers and
DNS authorities which only had AAAA records on a subset of their
names, Philipp Tiesel identified an interesting corner-case which we
should be aware of (and perhaps document).

Unfortunately draft-ietf-dnsop-3901bis-17 is already passed off from
the IESG for publication or we'd want to include it there.

The issue is when a DNS authorities have NS record names with A
records but not AAAA records, although the reverse is likely also
true.  During a DNS resolution, some resolvers (specifically Unbound
but there may be others) may take a miss on authorities/glue and need
to resolve the NS record names.  When those resolutions fail (due to
NXDOMAIN but also due to NODATA) they increase a counter, and when
this crosses a threshold they fail the resolution.  In Unbound's case
this limit is due to Unbound's defenses against glue hunting in
response to CVE-2020-12662.

When the resolver needs to hunt for an authority by resolving the
A/AAAA records for NS records, it is entirely reasonable for it to
have some total defenses against a large percentage of them returning
NXDOMAIN/NODATA.  This likely has perf issues as well (eg, in having
to hunt around for a reachable address record).

I think the general guidance is probably that all names pointed to by
NS records should be strongly encouraged to have both A and AAAA
records.  The text in
https://www.ietf.org/archive/id/draft-ietf-dnsop-3901bis-17.html for:

> To maintain name space continuity, every DNS zone MUST be served by at least two authoritative DNS servers providing services via IPv[46]

Doesn't cover this corner-case which happens when too many
authoritative DNS servers are configured in delegations which lack
either IPv4 or IPv6.

For example:

www.example.com CNAME www-example-com.cdn.example.
www-example-com.cdn.example. CNAME a1343.shard5.cdn.example.
where cdn.example. delegates to shard5.cdn.example.

In this, Unbound's limit of 2*MAX_TARGET_NX (== 10) is cumulative.
So if:
* example.com has 2 of 5 names having no AAAA,
* cdn.example. had 5 of 7 names having no AAAA
* shard5.cdn.example. had 5 of 7 names having no AAAA

Then some resolution paths will try to resolve 12 authority names and get NODATA
and then will bail out due to that being over the safety limit.
Sometimes this will work if it finds
the right names in the right order, but other times it will fail.
This is despite all
of the names meeting the "every DNS zone MUST be served by at least
two authoritative DNS servers providing services via IPv[46]"
criteria.

(This of course also has impacts since the resolver needs to hunt for
things that resolve.)

I'm guessing this is too late for draft-ietf-dnsop-3901bis and too
substantive for an errata.
I think the reasons for Unbound to do things this way are legitimate
(so not a bug on their  side).
A recusive using NAT64 wouldn't have this problem, but I think we do
want to aim for a world
where people can reasonably deploy true IPv6-only resolvers.

Best,

    Erik