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

[Erik Nygren <[e-mail]>]

Comments inline on the two wanting more discussion.

On Tue, May 19, 2026 at 1:59 PM <[e-mail]> wrote:

> 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.
>
> > -----Message d'origine-----
> > De : Tobias Fiebig <tobias=[e-mail]>
> >
> > > > 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.


I'd agree with your example that *if* a client subnet is sent the same
response should be returned regardless of if that query was over IPv4 or
IPv6 as its transport.  In the client subnet case the nameserver IP is
irrelevant.

Where this matters is for the case where there is no client subnet and the
answer depends on the nameserver IP.  This is done widely in practice (eg,
different answers based on the ISP or Country of the nameserver) and
handling this case was one of the major blockers for adding IPv6 DNS
authorities.  This is one of those cases where the long-standing present
reality of what is implemented differs from what RFCs specify.  My concern
is that a MUST here doesn't match what is actually widely implemented so
could be misleading.  Maybe a way to weasel out of this would be to switch
from "identical" to "equivalent" ?  For example:

   "Consistency: Both IPv4 and IPv6 transports MUST serve equivalent DNS
data to ensure a consistent resolution experience across different network
types."

This equivalence is important -- eg, if you make a decision for "handle
Country X specially" for IPv4 then it is important to do the same for IPv6.

("Identical" has other issues since things like RRset order randomization
means they will never truly be identical.)



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



The latter makes sense to me.  It is perhaps less precise but I believe it
is easier to read and understand.

Thank you for considering these suggestions at this late stage!

Best, Erik






> > 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.
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>