Subject: Re: [dhcwg] Revision of DHCPv6 DNS configuration options

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Feb 2003 23:12:46 -0600

> Caching name server is only one special kind of name servers.
> I don't think the option is limited to specify caching name servers 
> only.
> I think domain name server is more general and appropriate here.

The purpose of this option is to tell the client where it should send 
DNS lookups for final resolution.   Not all name servers are configured 
to do recursive name resolution for nodes with stub resolvers.   Some 
name servers, for example, only serve the zones for which they are 
primary or secondary, and refuse requests for recursive lookups.   So 
it is actually meaningful to make a distinction here.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Jun Xie <[email-masked]>
Date: Sat, 01 Mar 2003 11:17:29 -0800

At 11:12 PM 2/28/03 -0600, Ted Lemon wrote:
>>I don't think the option is limited to specify caching name servers only.
>The purpose of this option is to tell the client where it should send DNS 
>lookups for final resolution.   Not all name servers are configured to do 
>recursive name resolution for nodes with stub resolvers.   Some name 
>servers, for example, only serve the zones for which they are primary or 
>secondary, and refuse requests for recursive lookups.   So it is actually 
>meaningful to make a distinction here.

Nothing prevents a stub resolver from sending further queries to the server
referred by an iterative server, although many implementations don't do it.
In an isolated site, I think the option can also be used to configure name
servers that serve the local zones only, for local DHCP clients. Since
those
clients can go beyond the site

---

From: Jun Xie <[email-masked]>
Date: Sat, 01 Mar 2003 11:29:34 -0800

Nothing prevents a stub resolver from sending further queries to the server
referred by an iterative server, although many implementations don't do it.
In an isolated site, I think the option can also be used to configure name
servers that serve the local zones only, for local DHCP clients. Since
those clients can not go beyond the site, the answers they get from the
servers are final resolution for them. If the option really represents name
servers that can do recursive resolution, this should be clearly specified.
Even in this case, "name server" is still more appropriate than "resolver"
for the name of the option.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 2 Mar 2003 19:45:36 -0600

> Since

I don't think it's useful for us to continue discussing this.

---

From: Robert Elz <[email-masked]>
Date: Mon, 03 Mar 2003 11:11:30 +0700

Date:        Sat, 01 Mar 2003 11:29:34 -0800
    From:        Jun Xie <[email-masked]>
    Message-ID:  <[email-masked]>

  | Nothing prevents a stub resolver from sending further queries to the server
  | referred by an iterative server,

No, but the point of the option is (or should be) to provide the addresses
of "things" for which that will not be required - that is, things which will
do recursive resolution for the (stub) resolver.

If the stub resolver is able to do iterative resolution, then all it needs
is a list of the root servers, and I really don't believe this option should
be used for that - and it should be made clear that that isn't what should
be sent in this option.

It is truly unfortunate that the DNS has never created a name for this
"thing" which has stuck - "DNS server" was used originally, but many,
rightly I feel, object to that one as being too vague - a DNS server isn't
required to do recursive resolution, here we want a thing which will do
recursive resolution (at least for the clients being instructed to use it)
and so calling it a "DNS Server" isn't really the best idea.

Calling it a "resolver" is no better however, the resolver is the thing
that is going to be using this information really, and while a recursive
server can be thought of as a resolver, which gets its query passed to
it using DNS protocols, rather than the more usual function calls, it
is still a stretch on most people's interpretation of the term - that is,
using it suggests to people something other than what is intended.

I'd suggest using some label that is neither of those - and since the DNS
community has failed to produce a name for this thing, I see no reason for
this WG to not just go ahead and pick a suitable name, and define it.
With any luck, it can then transfer itself into the DNS lexicon, and
the whole DNS community will be grateful (trying to continually find some
good term which will unambiguously describe the thing that is of interest
here is a recurring nightmare - and has caused misunderstandings quite
often in the DNS world).

I have no particular suggestion to offer (if I had a really good one,
then perhaps everyone would be using it by now), but something along
the lines of "DNS cache server" or "DNS caching resolver" or perhaps
just "DNS cache".   What is clear however, is that whatever name is
used (including DNS server and DNS resolver) its function needs to be
clearly spelled out in this doc - either this will be a new term, or
the re-use of an ambiguous one, and so this doc cannot simply rely upon
saying "The address of a DNS XXX goes here" and just assume that what
a "DNS XXX" is will be clear to everyone (and once more for emphasis,
this applies whatever is substituted for XXX).

kre