Subject: RE: Stateless DNS discovery draft

From: [email-masked]
Date: Tue, 16 Apr 2002 18:13:04 -0700

Hello,

I may be wrong but Rob's and Hesham's discussion about configuration of the node (at this point) is to my opinion a bit off-tack from the original discussion. Thus, I do not want to comment on that discussion but Hesham's original question.

There my view on the issue is quite clear: For a simple node (phone, or a PDA) or for a node in a simple network (PC in home environment, etc. - no real administration), there has to be a way to use the DNS without running _any_ additional protocols to additional servers. I believe that the current 'dns discovery' draft fills that whole rather well. (Though, the title of the document does not really reflect the content - to my opinion).

Then the discussion about having further configuration done on the node, by DHCP or whatever other protocol, I would say is a different discussion. 

Cheers,

Jonne.

> -----Original Message-----
> From: ext Rob Austein [mailto:[email-masked]]
> Sent: Tuesday, April 16, 2002 10:34 AM
> To: [email-masked]
> Subject: Re: Stateless DNS discovery draft
> 
> 
> At Tue, 16 Apr 2002 17:48:10 +0200, Hesham Soliman wrote:
> > 
> > Ok, I should say that the functionality I'd like to see is the
> > ability to discover a DNS without relying on functional entities
> > other than the DNS. (not necessarily the entire node, but the server
> > itself, I think the term server is very clear and does not imply an
> > entire node).
> 
> Sorry, but it really is not clear enough to sift fact from confusion
> in some of the comments that people (not necessarily you) have made.
> 
> Ok, a "server" isn't a whole node, good.  But is it a process, or the
> entity listening to a particular well-known port, or a collection of
> subroutines that perform a particular set of conceptual functions?
> 
> If, say, a single process is listening to both port 53 and to port 67,
> is that one server or two?
> 
> > The point of the work is to limit the effects of third party node
> > failures on discovering the DNS. I.e. When I'm running a network
> > with a million user devices in it, I can either spend money to make
> > sure that my DHCP server is super reliable or, make sure that, at
> > least the very basic functions of the server, are done e2e. That is,
> > between the end host and the DNS.
> 
> So if the DHCP server role and the DNS server role were being
> performed by the same "server", this would not be a problem.  Right?
> 
> > Believe it or not, I think we're in agreement.
> > I was not referring to an entire node. 
> 
> Ok.
> 
> > Exactly, but propagating information across routers is _the_ issue
> > here. People were not comfortable with relying on multicast routing.
> > Also having an additional function in every router (relay agent) to
> > simply repackage this single packet didn't seem like a good
> > investment.  Hence the chosen 'transport' mechanism in the
> > draft. The content could well look identical to a DHCP message, but
> > the issue is how to send this packet across the network.
> 
> Right, and if I believed that DNS were the only non-addr-config data
> we'd ever need to worry about, I might buy the argument, but I don't.
> 
> > The other issue is, if we assume that the node containing the DNS
> > will also act like a DHCP server (for the sake of receiving this
> > single message (DHCP INFORM)), how does that work in the presence of
> > other DHCP servers used for address configuration as well as
> > configuring other parameters?  I've already claimed lack of deep
> > knowledge on DHCP, so there might be a pretty simple answer for
> > this, but I haven't heard it.
> 
> Well, entities performing the server role of DHCP only answer Inform
> requests when (they think) they have something useful to say.  The
> specific mechanism by which multiple entities could act in the DHCP
> server role on a single node is an implementation issue, but if you
> want an example, it appears (from the man page, I haven't tried it)
> that setsockopt(SO_REUSEPORT) would suffice on FreeBSD.
> 
> Thanks,
> 
> --Rob
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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: Tue, 16 Apr 2002 22:43:22 -0400

At Tue, 16 Apr 2002 18:13:04 -0700, jonne soininen wrote:
> 
> I may be wrong but Rob's and Hesham's discussion about configuration
> of the node (at this point) is to my opinion a bit off-tack from the
> original discussion.

I think it's the same discussion.  YMMV.

---

From: "Yamasaki Toshi" <[email-masked]>
Date: Wed, 17 Apr 2002 17:07:02 +0900

> There my view on the issue is quite clear: For a simple node (phone, or a
PDA) or for a node in a simple network (PC in home environment, etc. - no
real administration), there has to be a way to use the DNS without running
_any_ additional protocols to additional servers. I believe that the current
'dns discovery' draft fills that whole rather well. (Though, the title of
the document does not really reflect the content - to my opinion).

I absolutely agree.

In other word, there are typically three players,

1) end-host
2) site network
3) ISP network

and "Stateless DNS discoery" is a zero-configuration method mainly for 1).

When the administrator of 2) wants to prepare DNS servers in his/her site
with assigning the well-know-site-local-uni-cast-addresses to them, 1)
simply queries to them.

When the ISP prepares DNS servers in its backbone, the CPE router of 2) acts
as a dual-sited DNS proxy to relay queries to the the
well-know-site-local-uni-cast-addresses of the ISP's site, or to the global
addresses which are informed via ISP-to-Customer (or PE-to-CPE)
configuration mechanism such as DHCPv6, SLP or papers.

Toshi Yamasaki / NTT Communications

---

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Apr 2002 09:24:45 -0400

> There my view on the issue is quite clear: For a simple node (phone,
> or a PDA) or for a node in a simple network (PC in home environment,
> etc. - no real administration), there has to be a way to use the DNS
> without running _any_ additional protocols to additional servers.

To clarify:

Does this mean you are concerned about the need to configure other
servers manually? (i.e., if this were done automatically without admin
involvement, would that address the problem)?

From your followup note, it sounds like manual configuration is your
concern. You want this to happen without human configuration being
required.

Also, are you saying that it is NOT necessary for nodes (say at home,
in the "no real administration" environment) to have DNS names
associated with their addresses? If the answer is that they WILL need
DNS names, we need to talk about how that will happen, and if the
mechanisms needed to get DNS names into the DNS in fact means that the
simple DNS discovery turns out to NOT be enough (by itself) to be
sufficiently useful.

> Then the discussion about having further configuration done on the
> node, by DHCP or whatever other protocol, I would say is a different
> discussion.

Because you believe that all a node needs in practice is an address
and a DNS server it can send queries to? 

Thomas