On 31.8.2015, at 13.16, Henning Rogge <[email protected]> wrote: > On Mon, Aug 31, 2015 at 11:42 AM, Steven Barth <[email protected]> wrote: >>> Now could we achieve this in a multi-link Homenet without any >>> elections? >> >> The primary purpose of the election is to avoid having multiple different >> zones and names for the same link. It's not so much an issue of running >> multiple mdns proxies but mainly to avoid duplication. >> >> That's why the first tie breaker in the election favors routers that also >> offer other services as to centralize mdns and dhcp-fueled naming on a link. > Does homenet even need a “central" DNS server?
No. It is per link, not per home. > Typical configuration of a cheap router would be to run dnsmasq for > local DHCP and as a DNS cache. If each of these DNS caches could > forward DNS queries for *.<homenet-router-id>.homenet to the relevant > homenet router, it would not be necessary to pool all the information > in an elected DNS “master". For naming this works as is fine in our current implementation too; all you get is some duplicates (foo.link1.rid1.home and foo.link2.rid2.home may both exist, even if link1.rid1 is same link as link2.rid2). It isn’t even a problem; both forward and reverse stuff works out of the box this way (given hnetd, cough). For service discovery, shitload of duplicates (both on query path, and shown to the user) are a problem. > HNCP already knows the IP addresses and node-id's of all other homenet > routers, so the information which DNS server is to be asked is already > known. Each of the local DNS caches could use both the > (DHCP-delivered) hostnames and the MDNS ".local" zone to populate its > local DNS information. Yes. -Markus _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
