To:
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
CC:
dnsop@cafax.se
From:
"Eric A. Hall" <ehall@ehsco.com>
Date:
Tue, 29 Jul 2003 09:22:06 -0500
In-Reply-To:
<200307290158.KAA14710@necom830.hpcl.titech.ac.jp>
Sender:
owner-dnsop@cafax.se
User-Agent:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Subject:
Re: proposal for a compromise on DNS discovery
on 7/28/2003 8:59 PM Masataka Ohta wrote: > Huh? Multicast? It's no solution. As I commented to > By assuming large link layer, which violates the CATENET model, > many protocols, including but not limited to IPv6 and IGMP, > are damaged. > > Now, we can simply say, broadcast. > > link local multicast is a poor alternative to broadcast. I don't understand these complaints. ~512 bytes isn't very large, and broadcast is a poor alternative to admin scoped multicast. > In addition, DNS with link local multicast/broadcast does not solve > any configuration problem. Which configuration problem? It wouldn't give a hostname if that's what you mean, but I'm not sure that anybody would expect such. > Multicast for domains larger than a link beyond routers requires > domain wide broadcast (such as that of data broadcast of DVMRP > or core/RP selction of CBT/PIM) or static configuration (such as that > of core/RP/source of CBT/PIM/SSM). It would need static configuration in a non-optimized state. One of the challenges for a multicast DNS would be to keep multiple servers from always replying to every query, and that could be accomplished through numerous methods, any of which may in turn could minimize the need for manual maintenance of the multicast address. It's also possible to limit the use of multicast to DNS discovery, such as having clients issue (periodic) queries to the multicast address to determine the available servers, and to choose the top 3 servers (or whatever) based on certain criteria (RA flag, response time, whatever), and then use unicast after that. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ #---------------------------------------------------------------------- # To unsubscribe, send a message to <dnsop-request@cafax.se>.