On Nov 13, 2014 2:58 AM, "Michael Richardson" <[email protected]> wrote: > > > STARK, BARBARA H <[email protected]> wrote: > >> Why can't we make a similar assumption that a homenet can get a dns > >> delegation from some upstream provider as well, be it an ISP, or some > >> other DNS serving entity? There is no requirement that I have my own > >> vanity domain and pay a registrar to get a delegation in somebody > >> else's name space, though I can do that if I want. Why can't we work > >> from that assumption too? > > > I think it's dangerous to assume all people *want* dns delegation. Or, > > if a person does want it for certain hosts, to assume they want it for > > *all* hosts in the home. Barbara > > We seem to keep having the same conversation. > I wonder if this pretty much sums it up. > > It does like this: > 1) Mechanism FOO permits a CPU to offer hosts in the home a way to publish > a populated forward (reverse) DNS zone. > (1B - but lots of ISPs do not want to do this.
> (1C - mechanism FOO can be used by any service provider, and maybe > you have more than one ISP) We already added features to dnsmasq that make it possible to have more than oneupstream reverse resolver. > (1D - market forces might change this) I would certainly like otherwise vanity dns names to actually be useful. > 2) Home equipment is too weak to run DNS servers. At least on the now 7 year old cpe gear I work on, it proved utterly feasible to run an outward facing bind dns server, something like 3 years back. As continuing proof of concept lab.bufferbloat.net still runs bind with dnssec in a box with 64MB ram and 16MB flash. So do several isc devs. It didn't really prove desirable to run bind in these circumstances, as it is nearly impossible to configure bind via a web interface, and the binary was overlarge vs the amount of available flash, and due to 1 CVE per quarter, a PITA to keep upgraded - so we added the core features needed to dnsmasq (adding dnssec and slave zone push), and others are using unbound, also. The latest generation of home APs have gobs more flash (128MB or more), and ram, and when you compare the computational overhead of doing WPA, or pushing packets at gig speeds, the overhead of a local dns server is trivial, and it is very desirable to have a local caching server regardless.... Certainly more work is needed in this area - I'd like multiple local caching dns servers to easily co-exist (anycast in the homenet anyone?), and I'd like the work on mdns-proxy and hnetd to also be available in mainline linux, perhaps as part of systemd, and other OSes besides those openwrt-derived. > (2A - it's not .com, mechanism FOO means the CPE runs a server, but it > might be a stealth primary) I think the stealth primary approach is a good one. > (2B - we need home DNS to resolve in the home, insert DNSSEC considerations) Well it does, and has for over a year now. > 3) Lightbulbs can't be configured with DNS names, they don't have keyboards. Sigh. mdns has a mechanism to auto-rename devices that present the same name, dhcp can be used to do the same, and users have the ability to easily name devices from the mac address. You plug all your devices in, you look at the web page on the router showing the mac addresses in use, and you give them all names that are logical for your setup. > (3A - lightbulbs have APIs) > (3B - lightbulbs have controllers which have web servers) > (3C - not all lightbulbs need names, but other things might) > 4) you can't just fill the zone with all the names -- it won't be secure. Well, there is another concern in that you don't want to export rfc1918 or ula addresses into the global namespace. > (4A - things that don't want global reachability, perhaps, shouldn't > have globally reachable addresses) > (4B - things that want global reachability, probably want global names) This is kind of hard. As for the security concern, lightbulb-1.taht.net needs to be guessable, random walks of the dns take a long time... but with the rise of dhcpv6, guessing from a reverse lookup is tons easier (this is partially why I still favor SLAAC and privacy addresses vs dhcpv6 in the home) I would argue for a simple switch (publish all valid addresses in the global dns/only publish selected) in the cpe, defaulting to the latter option. I would certainly like to see some sort of DHT for rendezvous be standardized for things like webrtc to supercede dns as a main mechanism for sharing information about your machine and location. > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails [ > > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
