> 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.
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 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
