[DNSOP] Re: libc 3 resolver limitation and draft-ietf-dnsop-3901bis (was Gorry Fairhurst's No Objection on draft-ietf-dnsop-3901bis-15: (with COMMENT))

[Erik Nygren <[e-mail]>]

>
> 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).


I agree there are two separate issues:

1) The one mentioned in the draft where only a subset of resolvers have the
ability to resolve for each address family.  This is certainly a problem of
its own -- I wonder how well various stub resolvers deal with this?  Having
different partial connectivity from different stub resolvers but configured
as the same may confuse some of the stub resolvers and will cause
performance issues.  I'm unconvinced that having a subset of them
dual-stacked is good enough to avoid problems, as many stubs aren't good
with handling cases where their recursive resolvers have partial
functionality.

2) The one I'm raising where it is important to make sure the client
receives at least one recursive resolver its stub resolver or stub library
can reach is separate/distinct.   This isn't covered in the current draft,
but I agree that it is messy enough that it is likely hard to cover with
just a small update here.  (I'm actually not sure there is a heuristic that
always works.)

Best, Erik


On Tue, May 5, 2026 at 11:29 AM Tobias Fiebig <[e-mail]> wrote:

> 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]
>