> > 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 <[email protected]> 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 +31 616 80 98 99 > M [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
