Subject: Re: Proposed IPv6 DNS Discovery Requirements

From: Bob Hinden <[email-masked]>
Date: Fri, 26 Apr 2002 15:38:35 -0700

Rob,

Sorry for not responding sooner.

The emphasis in the definition is "with out any dependence on resources 
other than are needed".  This would allow relay agents in routers or DHCP 
servers in DNS servers.

There are issues raised in solutions like this to insure that the 
co-located services are adequately tied together.  For example in case of a 
"DHCP server in the DNS server" the processes need to be tied together in a 
manner that the DHCP process would not provide the address of the DNS 
server if the DNS server process was down.  Or that the DHCP server not 
provide the addresses for other DNS serves unless it knows that they are up 
and available.

So I think the examples you raised do fit with the definition.  My intent 
was that the requirements should allow for a of number different 
solutions.  Picking a specific solution requires evaluating the strengths 
and weaknesses of the specific solution.  I think this falls into the 
"Desirable aspects" part of the text, as opposed to the basic requirement.

Bob

>However, since you did ask a direct question, I'll try to answer it.
>
> > For this requirement, Server-less is defined to mean the DNS
> > information is learned with out any dependence on resources other
> > than are needed (i.e., links, interfaces, routers, and DNS server)
> > to communicate with the DNS server.
>
>Comments:
>
>   The term "DNS server" is not well defined at the level of detail
>   that this problem statement requires.  Is an entity that implements
>   both the DNS server role and portions of the DHCP server role a "DNS
>   server" within the meaning of this definition?
>
>   The term "router" is not well defined at the level of detail that
>   this problem statement requires.  Eg, would DHCP relay agents
>   co-resident with routers be parts of the routers within the meaning
>   of this definition?
>
>In all seriousness: I can't tell you whether I agree with your
>statement of the problem until I know what what the words mean.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Rob Austein <[email-masked]>
Date: Sun, 28 Apr 2002 03:41:28 -0400

> provide the addresses for other DNS serves unless it knows that they are up 

I suspect that upon close examination all solutions will have issues
along these lines (anycast certainly does).

In any case, I agree that such issues are part of the analysis.

> and weaknesses of the specific solution.

Ok, thanks.

---

From: Thomas Narten <[email-masked]>
Date: Mon, 29 Apr 2002 10:18:40 -0400

> provide the addresses for other DNS serves unless it knows that they are up 

To clarify, are you saying that it is a requirement that a DNS server
discovery mechanism only return the addresses of servers that are
currently functioning?  If so, I think this needs to be discussed
more, because I think there are alternatives that may well also be
acceptable.

In the case of DNS, it is not required that a client have a single
address of a single DNS server that is up and running. In practice, a
client has the addresses of 2 or 3 DNS servers, and switches from one
that is not working to one that is working as needed. Thus, it seems
quite acceptable for a DNS server discovery mechanism (whether DHCP or
something else) to return a list of candidate DNS servers (all of
which will _hopefully_ be working, but _some_ of which may _not_), and
let the client resolver do its normal thing to find a working server.

Note, if a DNS server discovery mechanism returns a single working
server, the client is likely to cache the result for some time
anyway. If that server goes down, the client now has the address of a
non-working server, so it needs to deal with the problem of
non-working servers already. Given this, it's not clear to me what the
benefits are to require a DNS discovery mechanism _only_ return DNS
servers that are current functioning.

Clearly, some coupling will be needed between the DNS server providing
service and the DNS discovery mechanisms advertisement of that
service. But it's not clear to me that a tight coupling (e.g., must
reside on same node, be part of the DNS process, etc.) is necessary
either.

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Mon, 29 Apr 2002 08:22:19 -0700

Thomas,

>more, because I think there are alternatives that may well also be

I did not state it as a requirement.  I was discussing it under the heading 
of "Desirable aspects" of a solution.  I wrote in the last paragraph of my 
email:

   "Picking a specific solution requires evaluating the strengths and
    weaknesses of the specific solution.  I think this falls into the
    "Desirable aspects" part of the text, as opposed to the basic
    requirement."

Bob