In message <[email protected]>, Steven Barth writes: > > > On 01/09/2015 01:06, Mark Andrews wrote: > >> > >> Why is topology being forced into the naming? DNS is independent > >> of topology. We have *a* home. I really don't care what link my > >> printer is connected too. It is not something I want to see in its > >> name unless I put it there. > > > > No-hat: > > > > I'm very much with MarkA on this one. > > > > I want my devices to have a persistent name identifier, regardless of > > which part of the topology they happen to be plugged into at the time. > > > > I wouldn't mind if the "canonical" identifier happens to be topology > > dependent, so long as there's some mechanism (e.g. CNAME) to > > automatically map the persistent identifier to the topology-dependent one. > > > Please consider the following thoughts in no particular: > > > * In each "zone" collisions need to be handled gracefully. > ** Also: there can be legitimate reasons for having devices with the same > (per-link) name in different parts of your network and if you > do service-discovery it can even be useful to know where the > device you found is located / what it is connected to (e.g. > printer.ethernet.office.home vs. printer.wifi.children.home)
and people will then want search lists which will become unmanagable as they want simple names. > * We currently have 2 sources of names from devices: MDNS and DHCP(v6), > it is complicated to extend them from their natural per-link to a multi > - > link scope. > ** MDNS does conflict resolution per link, extending it to multiple ones > is problematic (c.f. draft-ietf-homenet-hybrid-proxy-zeroconf-00#append > ix-C) > ** Implementing multi-link hostname conflict resolution in DHCP(v6) servers s > ounds > very painful (besides there are enough people already that don't even w > ant > to have stateful DHCPv6 by default). And the DNS has conflict resolution mechanisms that work over DNS UPDATE that are mangaged by the client. See prerequisites in UPDATE. DHCP uses these mechanisms today to prevent DNS entries it manages from overwriting "static" entries or entries from other DHCP servers. > * Having full-blown DNS-servers supporting zone transfers etc., on each and e > very > router puts a huge additional burden on implementers, personally I don' > t > see having a bind9 or similar on every router as very realistic or desi > rable. > For some schemes a single one per network might but enough, but that wo > uld put > the burden on the user to know, care and buy / install the "one". Zone transfers really take the abosolute minimum of code. Go look at the code that implements zone transfers and compare it to the rest of a nameserver. It really isn't hard to walk a database and add the records to you find to a message and send it. It also isn't hard to read records from a message and add them to a database. Named has additional code to allow a multiple version of a zone to be being transfered simulaneously while updates are being processed. It needs this code as some of the zones are gigabytes in size and you really can't afford to abort these or fork the nameserver (BIND 4 and BIND 8 did this). A simple implementation just aborts the zone transfer on update and for the typical home zone it all fits in a single DNS/TCP messages (<64k) there is nothing to abort. The root zone fitted into a single DNS/TCP message for decades. > * As noted by someone else in this thread, (most) users don't know about or a > ctively > use hostnames, so indiscriminately publishing all of them in a top-leve > l zone > and syncing them across the network might not be worth it. > ** Many auto-generated hostnames are very opaque (e.g. foobar-a18cb3) and wit > hout > additional service discovery information are relatively useless to a us > er, > in presence of service discovery information though the names become le > ss > relevant. > ** All that said, HNCP is already suitable to publish top-level hostnames und > er .home, > for a selected set of devices. > > > Resolutions for some or all of these issues are of course welcome. > > > > Cheers, > > Steven > > _______________________________________________ > 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
