Re: [dhcwg] Re: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

    Date:        Fri, 21 Feb 2003 07:56:20 -0500
    From:        Ralph Droms <rdroms@cisco.com>
    Message-ID:  <4.3.2.7.2.20030221074927.03e89ed8@funnel.cisco.com>

  | Shouldn't the host receive the same answer to a DNS query, regardless of 
  | the resolver to which the query is sent?  If so, the order in which 
  | resolvers are used by the host shouldn't matter.

It shouldn't matter to the answer (but those who insist on shoving 2faced
DNS implementations down everyone's throats can cause problems).

It can matter to the workability - often the first resolver listed is
the one that should be used, the others are there for backup purposes
only, and won't necessarily respond as quickly (they may have smaller
cache capacity, slower net links, slower CPU, ...).

All this is fine as a backup when the primary resolver happens to be
broken, but you wouldn't want to be using it just because you happened
to pick the wrong address from a list.

  | What is done today in the deployed IPv6 world in a host that has both an 
  | IPv6 stack and an IPv4 stack, and a manually configured list of DNS 
  | resolvers?

Just about everyone uses IPv4 alone for their resolvers.

  | Is it allowed to mix together IPv6 and IPv4 addresses for resolvers?

Allowed, yes, of course, nothing disallows it.

  | Is that configuration actually used?

Probably not at the minute.

  | Does the host have two lists: one for IPv6 and one for IPv4?

This would make no sense.   The host (or application in most cases)
has one resolver (stub).  When called, all that exists is a domain name,
there's no particular v4 or v6 preference.  The resolver stub needs to
contact its back end resolver to resolve the address, whether v4 or v6
is used for this will depend entirely upon what addresses have been
configured for the back end resolver (cache).  It certainly isn't
influenced by the nature of the query, or by what use is intended
for the results of the query.

  | Suppose the host only has an IPv6 stack but both IPv6 and IPv4 addresses in 
  | its list of DNS resolvers?

The v4 address would be useless, just like any other (patently) bogus
address that is configured.   Ignoring that one would be easy.

  | I'm hoping we can get some real-world deployment experience injected into 
  | the conversation...

Since just about no-one is using v6 in their stub resolvers (just a few
who will no doubt now speak up...) this might be difficult.

On the issue - I think having just v6 addresses in the DHCPv6 option is
fine.

How the host actually mixes addresses it gets from DHCPv6 and DHCPv4, and
other mechanisms is an interesting problem to which we don't yet have
any real answers.   This is an area where we probably should just say
nothing, and wait to see how implementations actually react.

But rather than mixing v6 & v4 addresses in one response (as you imply, v6
addresses are no use to a node with only v4, and v4 addresses no use to
a node with only v6) it might be better to explicitly add a "priority of
this DNS cache" field along with each address.  This allows the implicit
"this one is better than that one" based upon ordering to be done away with.
What's more, if we were to pick a middling well known priority that would
implicitly be applied to addresses in a v4 response it also allows v6 to
be placed before, or after, v4 addresses in nodes that support both (or
even some before, and some after).   It doesn't allow v4 addresses to be
ranked other than by their implicit ordering, nor for v6 addresses to be
inserted in the middle of the v4 list, but we can't have everything (and
I doubt anyone wants to go changing the v4 DNS cache list option now).

kre

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg