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

[[e-mail]]

Hi Erik, all, 

I'm not commenting at this stage on the technical aspects but on the process:

> I'm guessing this is too late for draft-ietf-dnsop-3901bis and too
> substantive for an errata.

draft-ietf-dnsop-3901bis is not published yet. We still have the possibility to correct things or make minor changes (assuming WG consensus of course) during AUTH48.

If you believe a change is needed, I strongly recommend that you share a draft text. For example, this can be a short note to increase awareness about the case you flagged. Having a concrete proposal will help with the discussion and decision. Thanks.

I'm monitoring both threads you initiated.

Cheers,
Med

> -----Message d'origine-----
> De : Erik Nygren <[e-mail]>
> Envoyé : vendredi 1 mai 2026 19:47
> À : dnsop WG <[e-mail]>; [e-mail] list
> <[e-mail]>
> Objet : [v6ops] Corner-case in DNS authority guidance impacting
> IPv6-only resolvers
> 
> 
> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.ietf.org%2Farchive%2Fid%2Fdraft-ietf-dnsop-3901bis-
> 17.html&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cc62262cd10
> ab4e1408ab08dea7a9df0e%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> 7C639132545208843338%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd
> WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> 3D%3D%7C0%7C%7C%7C&sdata=peUP9fg9kQK5lFVx6DkGAg9podAGN8HEEuyGDtU6o
> YE%3D&reserved=0 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:
> 
> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.example.com%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C
> c62262cd10ab4e1408ab08dea7a9df0e%7C90c7a20af34b40bfbc48b9253b6f5d2
> 0%7C0%7C0%7C639132545208858678%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI
> ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jaTh%2BJpiCvpq45So49vP50MjDN9GR
> IIsacWy%2FixTvPM%3D&reserved=0 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
> 
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.