In message <[email protected]>, Ray Bellis wr ites: > > On 5 Mar 2012, at 15:15, Kazunori Fujiwara wrote: > > > RI see. DHCP has enough function. RFC 2132 defines DHCP client host > > name option, and RFC 4702 Section 3.2. "Client Desires to Update A > > RRs" defines the option to DNS RR. > > > > # I'm not aware that DHCPv6 has the same option. > > Me neither, although whether DHCPv6 actually gets used within the Homenet (as > opposed to standard Neighbor Discovery) remains to be seen. > > > Using DHC client host name option is easier than implementing DNS > > Update client in each client. > > Agreed, and it removes the need for the TSIG key management normally required > for DNS Dynamic Updates.
A significant percentage of home machines will roam and those machines will need to be able to register their current address in the DNS. I do this today when my Mac roams. TSIG is unavoidable and cheap. UPDATE itself is relatively cheap. For PTR records TCP is a good enough authenticator for UPDATE. > >> 1. naming updates and queries between subnets > > > > One upstream, and multiple subnets case, it may be solved by using one > > DHCP server and multiple DHCP relay agents. > > I was more thinking about mDNS - there's no standardised mechanism (although > drafts are forthcoming) for using "link-local mDNS" in multiple segments. > > The options would appear to be either a multicast relay agent running on inte > rnal CPE, or an enhancement to mDNS to support "site-local" multicast. > > > Multiple upstream case, manual configuration is necessary. An end > > user setup one DNS server which serves local zone and multiple > > reverse zones. DHCP servers send updates to the DNS server. > > The unicast case is likely simpler, but we also need to beware the case where > the entire Homenet stops working because of the failure of a single "super n > ode". > > >> 2. integration (or otherwise) of unicast DNS and mDNS > > > > It is same as now. > > Using different TLDs solves the problem. > > It does, but without my co-chair hat on, I would prefer not to have different > namespaces for unicast vs multicast naming and discovery mechanisms. > > > >> 3. DNSSEC validation > > > > DNS proxy can forward global queries to DNSSEC validators. > > There are a lot of people who think that DNSSEC validation should be done as > close to the host as possible. I'm inclined to agree with them. > > The downside is that one then needs a way to bootstrap the root's DNSSEC key, > and also a way to replace it should the RFC 5011 automated trust anchor upda > te mechanism become unusable. > > > Local zones does not require DNSSEC validation, I think. > > I'm undecided on that. > > > I thought to write I-D, but now, DHCP has enough capability, > > I will consider the issure more. > > Thank you - your input is much appreciated. > > Ray > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
