Late reply, sorry, I've been away. > > => I understand. Perhaps stateful is used to refer > > to the fact that they keep a record of the DNS > > address. But I agree that it is not really accurate. > > Do DHC servers do that? Are they *required* too? And if they do, so > what? I.e., DHC servers can easily be configured to say "all clients > should use DNS server XXX". I.e., they give the same config > information to everyone. Is this explicitely recorded on a > per-client > basis? I don't know that it is or needs to be or why that matters.
=> I wasn't suggesting that they keep records per device. But that it simply keeps records. > > > => 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). > > Why? => For maximum reliability and minimal cost. Having a third entity (with the associated management and reliability needs) will add cost (human and financial). Having another process on the same node doesn't necessarily mean that you can reach the DNS process of course. > > 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. > > I seriously have to wonder whether one can have a network with a > million users on it that *doesn't* have the need to > configure services > other than DNS and that won't be needing to run DHC. => Yes, that's a valid question. But since the DNS is vital for any communication people are likely to rely on it to discover proxies and other basic servers. > > > => Exactly, but propagating information across > > routers is _the_ issue here. People were not > > comfortable with relying on multicast routing. > > Well, if it is a requirement that any DNS discovery > solution NOT rely > on multicast, I think the WG needs to have that discussion and make > it a requirement of the problem. There has been only limited > discussion on this point so far. => We tried to document this in the DNS discovery analysis draft. Perhaps additional text is needed. Hesham -------------------------------------------------------------------- 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] --------------------------------------------------------------------
