Re: [homenet] Unicast DNS within the Homenet?
Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server anyway in Homenet, why don't we go for the classic enterprise set up that has run for years for IPv4, rather than trying to shoe horn locally assigned SLAAC addresses into global DNS? It's not as though you can buy any piece of domestic networking equipment today that does not support DHCPv4, so why not DHCPv6? So we'd have: Homenet router - ISP = DHCP-PD to learn prefixes [existing] in Homenet prefix allocation distribution [work in progress] DHCPv6 from the Homenet router to the ISP could be extended to communicate any ISP DNS domain settings to the Homenet [gap] elect/configure a unicast DNS server for Homenet [gap] run standard unicast DNS [existing] elect/configure a DHCPv6 server for use within Homenet [gap] The routers that are acting as clients for DHCP-PD would seem good candidates. run standard DHCPv6 server on local Homenet router[existing] configure DHCPv6 relay per Homenet router to point to Homenet DHCPv6 server[existing standard, although autoconfig is a gap for the election process] use DHCPv6 server to update DNS content using RFC 2316 Dynamic DNS update on behalf of end clients [existing] client - Homenet router RFC 3315 DHCPv6 based address configuration, and standard unicast DNS [existing] Then the client only needs to do stuff that is already incorporated in any operating system used in business. Or is this stateless /stateful war still too fresh in the collective IETF memory? Ted Lemon wrote: On Sep 11, 2012, at 11:17 AM, Kerry Lynnker...@ieee.org wrote: Can we explore how this auto-population might occur? It seems that to glean bindings from mDNS or LLMNR there would have to be at least (or exactly?) one agent per subnet. The natural place for the agent to reside is on the router. Presumably each agent learns the address of the DNS server via stateless DHCPv6. The DNS server would need to be configured with a TSIG for each agent. The agent hears multicast responses to lookups on its local link, then periodically updates the DNS server. I assume an alternative would be to auto-configure via stateful DHCPv6. Would that more or less of a configuration burden than the sketch above? Would work with existing devices? There are a couple of options being pursued in the DHC working group; the DHCP address registration process would be an obvious mechanism for leveraging DHCP to populate the DNS. The idea here is that you do RA+SLAAC, or RA+CGA, and then you contact the DHCP server to tell it what address you allocated and what name you want associated with it, and to get any local network configuration information you might need. However, of course this is new technology that isn't even standardized yet. I'd like it if homenet recommended implementing this, but I think another way of populating the DNS is through mDNS—when a host publishes its name in mDNS, it's assumed to be valid as long as no conflicting registration has been made locally. I don't particularly love this method because mDNS doesn't have the same duplicate detection features that DHCP does through the DUID, but it wouldn't be _worse_ than plain mDNS, and would allow the DNS resolver to query a consistent FQDN tree for local names, so that it would work whether you were attached to the local wire or not. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Unicast DNS within the Homenet?
On Sep 12, 2012, at 10:28 PM, Mark Andrews ma...@isc.org wrote: Which is a UI / product support problem. The Mac has DNS registration under Sharing. It requires manual entry of the TSIG key which currently has to be entered into the nameserver for each device. It could be made as simple as BlueTooth associations are. It's probably true that a homenet router could be set up to allow for DNS updates from remote locations using a TSIG or SIG(0) signature. It might be nice to list this as a feature if we feel it can be specified cleanly. But as you say, it would be necessary for third party devices to implement this, and in order for them to do that they have to perceive a need. It could happen; I just don't think it's going to be valued enough to motivate people do make the effort required to set it up. I think there are a lot of steps between where we are now and an environment where people see the need for this. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Unicast DNS within the Homenet?
In message 279cabeb-4dee-45c7-8cf2-8c34eac3c...@fugue.com, Ted Lemon writes: On Sep 12, 2012, at 10:28 PM, Mark Andrews ma...@isc.org wrote: Which is a UI / product support problem. The Mac has DNS registration under Sharing. It requires manual entry of the TSIG key which currently has to be entered into the nameserver for each device. It could be made as simple as BlueTooth associations are. It's probably true that a homenet router could be set up to allow for = DNS updates from remote locations using a TSIG or SIG(0) signature. It = might be nice to list this as a feature if we feel it can be specified = cleanly. But as you say, it would be necessary for third party devices = to implement this, and in order for them to do that they have to = perceive a need. It could happen; I just don't think it's going to be = valued enough to motivate people do make the effort required to set it = up. I think there are a lot of steps between where we are now and an = environment where people see the need for this. MacOS already supports this so clearly someone at Apple thinks there is a need. You turn on Active Directory in Windows and your machines will try to register themselves when on the road. This working group is looking at a paradigm shift in how home networking is done. We now have directly addressable machines on the home network. Publishing addresses to the world now makes sense for lots of reasons including we are now reachable. The nobody is doing now argument doesn't cut it here. Are we about enabling future development or styfling it? The world is slowly heading away from asymetric home links (cable/adls) to symetric home links (fibre) with enough bi-directional bandwidth for the home user to host whatever services that want to. We need to forward thinking enough to put in the infrastructure to support that. That means more than addresses being added to the DNS which is basically where integrated DNS/DHCP solutions stop. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Unicast DNS within the Homenet?
Fair counter point to my suggestion. Enterprises don't generally put laptops in public viewable DNS. Isn't your requirement to support highly mobile devices a good reason to avoid mDNS wherever possible? [mDNS being link local specific, and any extensions/gateways from mDNS to unicast DNS will also be local network specific, so your favourite coffee shop network may not support them] regards, RayH Mark Andrews mailto:ma...@isc.org 13 September 2012 03:02 Note updating DNS involves both FORWARD and REVERSE entries and the solutions can be different. My machines have names. Those names don't change as I move around the world. Random DHCP servers at coffee shops DO NOT have the ability to update the DNS entries for those names. They do have the authority to update the PTR records in in-addr.arpa and ip6.arpa namespaces. snip ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
