[DNSOP] Re: libc 3 resolver limitation and draft-ietf-dnsop- 3901bis (was Gorry Fairhurst's No Objection on draft-ietf-dns op-3901bis-15: (with COMMENT))
Erik Nygren <[email protected]> Sat, 16 May 2026 15:39:59 -0400
| Newsgroups | gmane.ietf.dnsop,gmane.ietf.v6ops |
|---|---|
| Message-ID | <CAKC-DJg1AweR9PvFr3Qkw+Pxoq0JYSXqg43-mJ6W96byE5U-SQ@mail.gmail.com> |
--===============8290579655147834104== Content-Type: multipart/alternative; boundary="0000000000006627a00651f47f98" --0000000000006627a00651f47f98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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=E2=80=AFAM Tobias Fiebig <[email protected]> wr= ote: > 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] > --0000000000006627a00651f47f98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:tahoma,sans-serif"><blockquote class=3D"gmail_quote" style=3D"marg= in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= x"><span class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"></= span> The problem you describe (which subset to pick if there are v4 and v6<br> resolvers, and how to make sure that a client at least receives one it<br> can _directly query_ per AFI) is, in my opinion, slightly tangential<br> (but very much related).</blockquote><br></div><div class=3D"gmail_default"= style=3D"font-family:tahoma,sans-serif">I agree there are two separate iss= ues:</div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-ser= if"><br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans= -serif">1) The one mentioned in the draft where only a subset of resolvers = have the ability to resolve for each address family.=C2=A0 This is certainl= y a problem of its own -- I wonder how well various stub resolvers deal wit= h this?=C2=A0 Having different partial connectivity from different stub res= olvers but configured as the same may confuse some of the stub resolvers an= d will cause performance issues.=C2=A0 I'm unconvinced that having a su= bset of them dual-stacked is good enough to avoid problems, as many stubs a= ren't good with handling cases where their recursive resolvers have par= tial functionality.=C2=A0=C2=A0</div><div class=3D"gmail_default" style=3D"= font-family:tahoma,sans-serif"><br></div><div class=3D"gmail_default" style= =3D"font-family:tahoma,sans-serif">2) The one I'm raising where it is i= mportant to make sure the client receives at least one recursive resolver i= ts stub resolver or stub library can reach is separate/distinct.=C2=A0 =C2= =A0This isn't covered in the current draft, but I agree that it is mess= y enough that it is likely hard to cover with just a small update here.=C2= =A0 (I'm actually not sure there is a heuristic that always works.)</di= v><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><br>= </div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif">= Best, Erik</div></div><div><br></div><div><br></div><div class=3D"gmail_quo= te gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May= 5, 2026 at 11:29=E2=80=AFAM Tobias Fiebig <<a href=3D"mailto:tobias@fie= big.nl">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail= _quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204= ,204);padding-left:1ex">Hello Erik,<br> <br> > > When providing multiple DNS servers to stub resolvers, network<br= > > > operators have to consider that various implementations can only<= br> > > configure a small set of possible DNS resolvers, e.g., only up to= <br> > > three for libc [MAN], and additional resolvers provided may be<br= > > > ignored by clients.=C2=A0 Hence, when providing more than three D= NS<br> > > servers to stub resolvers, operators SHOULD ensure that any rando= m<br> > > subset of three DNS resolvers from the provided list contains at<= br> > > least one recursive DNS server supporting DNS resolution via IPv4= <br> > > and<br> > > one DNS server supporting DNS resolution via IPv6.=C2=A0 A single= <br> > > recursive DNS server supporting dual-stack DNS resolution counts<= br> > > towards both requirements.=C2=A0 If this is not done, a client mi= ght<br> > > select a subset of recursive DNS servers that leads to address<br= > > > family<br> > > based namespace fragmentation.<br> > <br> > Unfortunately the problem isn't with address family based namespac= e<br> > fragmentation.<br> > It is that the DNS resolver provided is provided as an IP address not<= br> > a name, and how clients<br> > assemble these lists from various sources can be challenging.=C2=A0 Ho= w<br> > those resolvers<br> > behave when they recurse isn't necessarily relevant to the issue (= but<br> > is also an interesting case as well).<br> > For example, if a provider does what would seem like the obvious<br> > thing<br> > of "3 IPv4 resolvers, 3 IPv6 resolvers"<br> > then clients can (non-deterministically) end up with<br> > <br> > * 3 IPv4 (0 IPv6)<br> > * 3 IPv6 (0 IPv6)<br> > * 2 IPv4, 1 IPv6<br> > * 1 IPv4, 2 IPv6<br> > <br> > if either the resolver fails, or the clients' path to the resolver= <br> > fails, or the client lacks connectivity<br> > on one address family or the other then things break (or at least are<= br> > degraded).<br> > I'm not sure what our guidance would/should be here.=C2=A0 Ideally= clients<br> > would just accept the<br> > "3 IPv4 resolvers, 3 IPv6 resolvers" which works for things = like<br> > systemd-resolved but<br> > not for libc using resolv.conf<br> > <br> > Because I don't have a good answer (this is a hard problem with no= <br> > obvious "best practice")<br> > I'm not sure what we would want to put into the draft even if it<b= r> > hadn't been passed off for publication.<br> > I don't know if we want an errata that describes this challenge in= <br> > more detail, though?<br> > <br> > As a concrete example of how I've solved this in two different<br> > environments:<br> > <br> > Env1: Include 2 IPv4 and 1 IPv6 resolver deterministically, but with<b= r> > each being backed by a high-availability service.<br> > <br> > Env2: Include 3 IPv4 when we know there is public IPv4 access.<br> > Include 3 IPv6 when we know there is no public IPv4 access but only<br= > > public IPv6 access.<br> > <br> > (These are way too deployment contextual to be useful in this draft=C2= =A0 <br> <br> The guidance you quoted--at least as i read it--is not related to how<br> the three NS are being reached, but instead to which capabilities they<br> have in terms of DNS resolution.<br> <br> So, if an operator provides four NS via DHCP, e.g.:<br> <br> 192.0.2.1<br> 192.0.2.2<br> 192.0.2.3<br> 192.0.2.4<br> <br> Two of these would have to support dual-stack DNS resolution themselves<br> (and, technically, all of them should).<br> <br><span class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><= /span> The problem you describe (which subset to pick if there are v4 and v6<br> resolvers, and how to make sure that a client at least receives one it<br> can _directly query_ per AFI) is, in my opinion, slightly tangential<br> (but very much related).<br> <br> > --<br> > it may be that if this is impacting enough folks this is worth its<br> > own separate Informational draft.)<br> <br> I would personally argue that this would be the best way forward. There<br> are a lot more deployment considerations in there, also differentiating<br> between access/server systems etc.<br> <br> As such, I'd kind of prefer to write a 'full' I-D on this, inst= ead of<br> an eratta.<br> <br> With best regards,<br> Tobias<br> <br> -- <br> Univ.Prof. Dr.-Ing. Tobias Fiebig<br> T +31 616 80 98 99<br> M <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a= ><br> </blockquote></div></div> --0000000000006627a00651f47f98-- --===============8290579655147834104== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============8290579655147834104==--