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

[Tobias Fiebig <[e-mail]>]

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]