On 23 Nov 2016, at 19:45, Juliusz Chroboczek <[email protected]<mailto:[email protected]>> wrote:
- ohybridproxy (only really scalable and sensible IPv6 rdns source that I am aware of, given nodes talk mdns) Noted, thanks for the opinion. I still don't understand how it works (who gets port 53? how are data from multiple links merged?), but I intend to do my homework. I give dnsmasq port 53, and then have it forward queries for .home (chuckle) and my IPv4/IPv6 reverses in .arpa-land to 127.0.0.1:54 where ohp listens on my routers. Ok, makes sense (except for the choice of 54). Two more questions: - who merges data from multiple links? (I'd wish that the hybrid proxies compute a minimal spanning tree and perform peer-to-peer magic, but I suspect you're generating a config file dynamically and restarting dnsmasq whenever the set of hybrid proxies changes.) In dnssd we have the “stitching” topic on our plate, around operation of dns-sd in unmanaged multi-link networks. So this is timely discussion. We’re beginning work on a BCP for the use of the discovery/advertising proxy in enterprise/campus networks, where there is administrative configuration, and scalability is a concern. The stitching topic would likely form part of a corresponding BCP for unmanaged operation, as per a multi-link homenet. - who speaks mDNS? The Hybrid proxies? Or do they communicate with a dedicated mDNS speaker? The proxies ask about (discover) services on the link(s) they serve on behalf of the (remote) querier. For general info on how dns-sd works, see https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-05, Section 5 in particular. For info the “hybrid proxy” has been renamed the “discovery proxy”, which will be reflected in the -06 draft, and Stuart will be publishing a separate “advertising proxy”, which will allow (remote) proxy advertisements of services in addition to proxy discovery of them. For more info on that, see https://www.ietf.org/proceedings/97/slides/slides-97-dnssd-hybrid-proxy-00.pdf The other thing to be aware of is that there is “long lived query” support for the proxies being defined via the DNS Push Notifications and DNS Session Signalling drafts (https://tools.ietf.org/html/draft-ietf-dnssd-push-09 and https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-01). These allow clients to get timely notifications of changes. Tim
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
