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 PROTECTED]] > Sent: Tuesday, April 16, 2002 10:34 AM > To: [EMAIL PROTECTED] > 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 PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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 PROTECTED] --------------------------------------------------------------------
