[DNSOP] Re: [v6ops] Corner-case in DNS authority guidanc e impacting IPv6-only resolvers
Erik Nygren <[email protected]> Sat, 16 May 2026 15:29:04 -0400
| Newsgroups | gmane.ietf.dnsop,gmane.ietf.v6ops |
|---|---|
| Message-ID | <CAKC-DJhiSAmgPkN-N=0PvixEQfnSW+icD2LNCEMHW+Lthj2UUw@mail.gmail.com> |
--===============2602206713839242256== Content-Type: multipart/alternative; boundary="0000000000007a94ed0651f4588f" --0000000000007a94ed0651f4588f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Tobias Fiebig <[email protected]> wr= ote: > 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 +31 616 80 98 99 > M [email protected] > > > > ---------- Forwarded message ---------- > From: Tobias Fiebig <[email protected]> > To: Erik Nygren <[email protected]>, dnsop WG <[email protected]>, " > [email protected] list" <[email protected]> > Cc: Gorry Fairhurst <[email protected]>, > [email protected], "Ond=C5=99ej Sur=C3=BD" <[email protected]= rg> > 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 +31 616 80 98 99 > M [email protected] > > _______________________________________________ > v6ops mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --0000000000007a94ed0651f4588f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Yes, I saw that one -- that was a response to a different = topic.<br><div><span class=3D"gmail_default" style=3D"font-family:tahoma,sa= ns-serif">I'</span>'d sent/started two separate threads on the same= day, perhaps confusingly<span class=3D"gmail_default" style=3D"font-family= :tahoma,sans-serif">, and your response</span></div><div><span class=3D"gma= il_default" style=3D"font-family:tahoma,sans-serif">in May that I saw and w= hich you quoted was below to the other thread.</span></div><div><span class= =3D"gmail_default" style=3D"font-family:tahoma,sans-serif"><br></span></div= ><div><div style=3D"font-family:tahoma,sans-serif" class=3D"gmail_default">= I can resend the one which didn't have a response that I can find.=C2= =A0</div><div style=3D"font-family:tahoma,sans-serif" class=3D"gmail_defaul= t"><br></div><div style=3D"font-family:tahoma,sans-serif" class=3D"gmail_de= fault">I will go and respond again to the one you did respond to, but back = on that thread.</div><div style=3D"font-family:tahoma,sans-serif" class=3D"= gmail_default"><br></div><div style=3D"font-family:tahoma,sans-serif" class= =3D"gmail_default">Best, Erik</div><div style=3D"font-family:tahoma,sans-se= rif" class=3D"gmail_default"><br></div><div style=3D"font-family:tahoma,san= s-serif" class=3D"gmail_default"><br></div></div><div></div></div><br><br><= div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"g= mail_attr">On Sat, May 16, 2026 at 5:17=E2=80=AFAM Tobias Fiebig <<a hre= f=3D"mailto:[email protected]">[email protected]</a>> wrote:<br></div><blo= ckquote 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> On Thu, 2026-05-14 at 19:02 -0400, Erik Nygren wrote:<br> > Bumping this thread again.=C2=A0 (I can appreciate that it is too late= to<br> > make these changes, but making sure this didn't get missed.)<br> <br> Thanks; Have you seen my reply from early May?<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> <br><br><br>---------- Forwarded message ----------<br>From:=C2=A0Tobias Fi= ebig <tobias=3D<a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a>><br>To:=C2=A0Erik Nygren <<a hr= ef=3D"mailto:erik%[email protected]" target=3D"_blank">[email protected]= </a>>, dnsop WG <<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a>>, "<a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a> list" <<a href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a>><br>Cc:=C2=A0Gorry Fairhurst <<a= href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= k</a>>, <a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a>, "Ond=C5=99ej Sur=C3=BD&q= uot; <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= rg</a>><br>Bcc:=C2=A0<br>Date:=C2=A0Tue, 05 May 2026 17:29:08 +0200<br>S= ubject:=C2=A0[v6ops] Re: libc 3 resolver limitation and draft-ietf-dnsop-39= 01bis (was [DNSOP] Gorry Fairhurst's No Objection on draft-ietf-dnsop-3= 901bis-15: (with COMMENT))<br>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> 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> <br> _______________________________________________<br> v6ops mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">v= [email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a><br> </blockquote></div> --0000000000007a94ed0651f4588f-- --===============2602206713839242256== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK --===============2602206713839242256==--