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

[[e-mail]]

Re-

> @Med: How should we go about these process wise? Add a new
> revision?

No need to submit a new revision. What I have seen so far are minor clarifications and edits that can be passed to the RFC Editor during AUTH48. 

Once the discussion converges, I suggest that you summarize the OLD/NEW changes. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Tobias Fiebig <tobias=[e-mail]>
> Envoyé : mardi 19 mai 2026 19:25
> À : [e-mail]
> Objet : [DNSOP] Re: [v6ops] Corner-case in DNS authority guidance
> impacting IPv6-only resolvers
> 
> 
> Dear all,
> 
> just reviewed these suggestions. Comments below.
> 
> @Med: How should we go about these process wise? Add a new
> revision?
> 
> > >  When providing multiple DNS servers to stub resolvers,
> network
> > > operators have to consider that, at the time of writing,
> 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 no more than two recursive DNS servers supplied to
> > > clients are unable to perform dual-stack DNS resolution, and
> at
> > > least one of the supplied recursive DNS servers is able to
> perform
> > > dual-stack DNS resolution. If this is not done, a client might
> > > select a subset of recursive DNS servers that leads to address
> > > family based namespace fragmentation.
> >
> > with:
> >
> > >  When providing multiple recursive DNS servers to stub
> resolvers,
> > > network operators have to consider that, at the time of
> writing,
> > > various implementations can only configure a small set of
> possible
> > > DNS resolver addresses, e.g., only up to three for libc [MAN],
> and
> > > additional resolver addresses provided may be non-
> deterministically
> > > ignored by clients. Hence, when providing more than three
> recursive
> > > server addresses to stub resolvers, operators SHOULD ensure
> that
> > > either 1) all supplied recursive server IPs are from the same
> adress
> > > family, based on knowledge as to clients being IPv4-only or
> > > IPv6-mostly; or 2) exactly two IPs are from one address family
> > > (IPv4 or IPv6) and exactly one is from the other address
> family.
> > > Furthermore, all suppled resolvers SHOULD be able to perform
> dual-
> > > stack DNS resolution to avoid address family based namespace
> > > fragmentation.
> 
> This looks reasonable to me.
> 
> > >  Similar to authoritative servers, (stub) recursive resolvers
> may
> > > face broken IP connectivity for either IPv4 or IPv6:
> >
> > The "(stub) recursive" should be replaced with "both stub and
> > recursive" -- this is incorrect as currently written.
> > The stub resolvers are what talk to the recursive resolvers and
> each
> > can independently have connectivity issues..
> 
> Works for me, would just adopt the suggestion.
> 
> > It would also be worth seeing if we can use a different word for
> > "fragmentation"
> > in some contexts.  Using "fragmentation" for both "IP
> fragmentation"
> > and "namespace fragmentation"
> > is highly confusing to the reader.  At a minimum we should
> always
> > qualify which form of fragmentation we are using and never use
> > "fragmentation" by itself.  Preferable might be to replace one
> of them
> > (eg, "namespace fragmentation" with "namespace divergence" or
> > "namespace partitioning" or "namespace consistency").
> >
> > This is especially the case in a section like "3.2. Network
> Conditions
> > Causing IP Address Family Related Name Space Fragmentation"
> > as some of the reasons for Name Space Fragmentation are IP
> > Fragmentation.
> > (Name Space Fragmentation is a Layer 7 issue, IP Fragmentation
> is a
> > layer 3 issue.)
> 
> I like namespace partitioning. This should, effectively, be an
> editorial change, no?
> 
> > > Consistency: Both IPv4 and IPv6 transports MUST serve
> identical DNS
> > > data to ensure a consistent resolution experience across
> different
> > > network types.
> >
> > This doesn't match against common practices for Global Traffic
> > Management systems like CDNs that use the IP address to
> determine what
> > answer to provide.  I'd strongly recommend switching to a
> "SHOULD"
> > (perhaps replacing "identical" with "equivalent").
> 
> I disagree with this one. A query to 2001:db8::53 with a client
> subnet of 192.0.2.0/24 for A example.com should also receive the
> same response as a query to 203.0.113.53 with a client subnet of
> 192.0.2.0/24 for A example.com.
> 
> In practice, however, this may (as you say) differ.
> 
> The problem is that RFC1034 Sec. 4.1 somewhat implies this
> consistency, while, IIRC, the above (even though lived practice)
> has never been formalized; So, going away from the MUST feels a
> bit like a too deep change.
> 
> I would need more opinions on this.
> 
> > The other proposed change to cover this thread would be in "4.1.
> > Guidelines for Authoritative DNS Server Configuration"
> > to add a sentence at the end of that section with:
> >
> >    "When a recursive resolver queries for A or AAAA address
> record
> > that are missing (due to an authoritative nameserver having only
> IPv4
> > or IPv6), a NODATA is received.  To prevent resolution failures
> or
> > performance issues from recursive recursive having to hunt for a
> > reachable DNS authority, the number of nameservers without both
> > reachable IPv4 and IPv6 address records SHOULD be minimized."
> >
> > or:
> >
> >    "When a recursive resolver queries for A or AAAA address
> record
> > that are missing (due to an authoritative nameserver having only
> IPv4
> > or IPv6), a NODATA is received.  To prevent resolution failures
> or
> > performance issues from recursive recursive having to hunt for a
> > reachable DNS authority, all authoritative DNS nameservers
> SHOULD be
> > configured with both IPv4 and IPv6 address records."
> 
> I would prefer the latter; But, again, I would really appreciate
> some more thoughts on this.
> 
> With best regards,
> Tobias
> 
> --
> Univ.Prof. Dr.-Ing. Tobias Fiebig
> T [phone]
> M [e-mail]
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.