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

[Erik Nygren <[e-mail]>]

Thank you.  For this case I'd propose replacing:

>  When providing multiple DNS servers to stub resolvers, network operators have to consider that, at the time of writing, various implementations can only configure a small set of possible DNS resolvers, e.g., only up to three for libc [MAN], and additional resolvers provided may be ignored by clients. Hence, when providing more than three DNS servers to stub resolvers, operators SHOULD ensure that no more than two recursive DNS servers supplied to clients are unable to perform dual-stack DNS resolution, and at least one of the supplied recursive DNS servers is able to perform dual-stack DNS resolution. If this is not done, a client might select a subset of recursive DNS servers that leads to address family based namespace fragmentation.

with:

>  When providing multiple recursive DNS servers to stub resolvers, network operators have to consider that, at the time of writing, various implementations can only configure a small set of possible DNS resolver addresses, e.g., only up to three for libc [MAN], and additional resolver addresses provided may be non-deterministically ignored by clients. Hence, when providing more than three recursive server addresses to stub resolvers, operators SHOULD ensure that either 1) all supplied recursive server IPs are from the same adress family, based on knowledge as to clients being IPv4-only or IPv6-mostly; or 2) exactly two IPs are from one address family (IPv4 or IPv6) and exactly one is from the other address family. Furthermore, all suppled resolvers SHOULD be able to perform dual-stack DNS resolution to avoid address family based namespace fragmentation.


While reading through again to see how to fit this change in,
there are a few other things I noticed that may also want to be
changed if possible:

>  Similar to authoritative servers, (stub) recursive resolvers may face broken IP connectivity for either IPv4 or IPv6:

The "(stub) recursive" should be replaced with "both stub and
recursive" -- this is incorrect as currently written.
The stub resolvers are what talk to the recursive resolvers and each
can independently have connectivity issues..

It would also be worth seeing if we can use a different word for "fragmentation"
in some contexts.  Using "fragmentation" for both "IP fragmentation"
and "namespace fragmentation"
is highly confusing to the reader.  At a minimum we should always
qualify which form of fragmentation
we are using and never use "fragmentation" by itself.  Preferable
might be to replace one of them
(eg, "namespace fragmentation" with "namespace divergence" or
"namespace partitioning" or "namespace consistency").

This is especially the case in a section like "3.2. Network Conditions
Causing IP Address Family Related Name Space Fragmentation"
as some of the reasons for Name Space Fragmentation are IP Fragmentation.
(Name Space Fragmentation is a Layer 7 issue, IP Fragmentation is a
layer 3 issue.)

> Consistency: Both IPv4 and IPv6 transports MUST serve identical DNS data to ensure a consistent resolution experience across different network types.

This doesn't match against common practices for Global Traffic
Management systems like CDNs that use the IP address to determine what
answer to provide.  I'd strongly recommend switching to a "SHOULD"
(perhaps replacing "identical" with "equivalent").

Best, Erik



On Mon, May 4, 2026 at 2:15 AM <[e-mail]> wrote:
>
> 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.
>