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

[Erik Nygren <[e-mail]>]

Yes, I saw that one -- that was a response to a different topic.
I''d sent/started two separate threads on the same day, perhaps confusingly,
and your response
in May that I saw and which you quoted was below to the other thread.

I can resend the one which didn't have a response that I can find.

I will go and respond again to the one you did respond to, but back on that
thread.

Best, Erik




On Sat, May 16, 2026 at 5:17 AM Tobias Fiebig <[e-mail]> wrote:

> Hello Erik,
>
> On Thu, 2026-05-14 at 19:02 -0400, Erik Nygren wrote:
> > Bumping this thread again.  (I can appreciate that it is too late to
> > make these changes, but making sure this didn't get missed.)
>
> Thanks; Have you seen my reply from early May?
>
> With best regards,
> Tobias
>
> --
> Univ.Prof. Dr.-Ing. Tobias Fiebig
> T [phone]
> M [e-mail]
>
>
>
> ---------- Forwarded message ----------
> From: Tobias Fiebig <tobias=[e-mail]>
> To: Erik Nygren <[e-mail]>, dnsop WG <[e-mail]>, "
> [e-mail] list" <[e-mail]>
> Cc: Gorry Fairhurst <[e-mail]>,
> [e-mail], "Ondřej Surý" <[e-mail]>
> Bcc:
> Date: Tue, 05 May 2026 17:29:08 +0200
> Subject: [v6ops] Re: libc 3 resolver limitation and
> draft-ietf-dnsop-3901bis (was [DNSOP] Gorry Fairhurst's No Objection on
> draft-ietf-dnsop-3901bis-15: (with COMMENT))
> Hello Erik,
>
> > > When providing multiple DNS servers to stub resolvers, network
> > > operators have to consider that 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 any random
> > > subset of three DNS resolvers from the provided list contains at
> > > least one recursive DNS server supporting DNS resolution via IPv4
> > > and
> > > one DNS server supporting DNS resolution via IPv6.  A single
> > > recursive DNS server supporting dual-stack DNS resolution counts
> > > towards both requirements.  If this is not done, a client might
> > > select a subset of recursive DNS servers that leads to address
> > > family
> > > based namespace fragmentation.
> >
> > Unfortunately the problem isn't with address family based namespace
> > fragmentation.
> > It is that the DNS resolver provided is provided as an IP address not
> > a name, and how clients
> > assemble these lists from various sources can be challenging.  How
> > those resolvers
> > behave when they recurse isn't necessarily relevant to the issue (but
> > is also an interesting case as well).
> > For example, if a provider does what would seem like the obvious
> > thing
> > of "3 IPv4 resolvers, 3 IPv6 resolvers"
> > then clients can (non-deterministically) end up with
> >
> > * 3 IPv4 (0 IPv6)
> > * 3 IPv6 (0 IPv6)
> > * 2 IPv4, 1 IPv6
> > * 1 IPv4, 2 IPv6
> >
> > if either the resolver fails, or the clients' path to the resolver
> > fails, or the client lacks connectivity
> > on one address family or the other then things break (or at least are
> > degraded).
> > I'm not sure what our guidance would/should be here.  Ideally clients
> > would just accept the
> > "3 IPv4 resolvers, 3 IPv6 resolvers" which works for things like
> > systemd-resolved but
> > not for libc using resolv.conf
> >
> > Because I don't have a good answer (this is a hard problem with no
> > obvious "best practice")
> > I'm not sure what we would want to put into the draft even if it
> > hadn't been passed off for publication.
> > I don't know if we want an errata that describes this challenge in
> > more detail, though?
> >
> > As a concrete example of how I've solved this in two different
> > environments:
> >
> > Env1: Include 2 IPv4 and 1 IPv6 resolver deterministically, but with
> > each being backed by a high-availability service.
> >
> > Env2: Include 3 IPv4 when we know there is public IPv4 access.
> > Include 3 IPv6 when we know there is no public IPv4 access but only
> > public IPv6 access.
> >
> > (These are way too deployment contextual to be useful in this draft
>
> The guidance you quoted--at least as i read it--is not related to how
> the three NS are being reached, but instead to which capabilities they
> have in terms of DNS resolution.
>
> So, if an operator provides four NS via DHCP, e.g.:
>
> 192.0.2.1
> 192.0.2.2
> 192.0.2.3
> 192.0.2.4
>
> Two of these would have to support dual-stack DNS resolution themselves
> (and, technically, all of them should).
>
> The problem you describe (which subset to pick if there are v4 and v6
> resolvers, and how to make sure that a client at least receives one it
> can _directly query_ per AFI) is, in my opinion, slightly tangential
> (but very much related).
>
> > --
> > it may be that if this is impacting enough folks this is worth its
> > own separate Informational draft.)
>
> I would personally argue that this would be the best way forward. There
> are a lot more deployment considerations in there, also differentiating
> between access/server systems etc.
>
> As such, I'd kind of prefer to write a 'full' I-D on this, instead of
> an eratta.
>
> With best regards,
> Tobias
>
> --
> Univ.Prof. Dr.-Ing. Tobias Fiebig
> T [phone]
> M [e-mail]
>
> _______________________________________________
> v6ops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>