>> Do you mean, (1) how is a DNS resolver advertised to clients, or >> (2) how clients are registered in DNS ? >> >> (1) is done by using the -N flag on the router advertising an external >> connection (-E). This flag can be repeated multiple times.
> hnetd grabs this automatically from wan-facing DHCP client, Yep. Shncpd might learn to act as a DHCPv4 and DHCPv6-PD client at some point. (But first implement IPv4 edge router election, which is one of the three missing features that I feel are necessary, security aside.) >> (2) is a host issue, so I believe it is better handled outside of shncpd, >> but I'm quite willing to be convinced otherwise. (The obvious alternative >> would be to have shncpd update DNS when it gives out a DHCP lease, but >> that would mean giving up on stateless autoconf.) > Well, DHCPv4 is stateful anyway, and you could in theory bind state from > there as well (at least if you do IPv4). Yes. I'm not sure how shncpd should update the state, though, since it doesn't act as a DNS resolver, it only passes the address of an existing DNS resolver to clients, and I don't want to bind it to any specific implementation of a DNS resolver. >> Markus, Steven, Ted? What's the plan here? Do we count on mDNS proxying, >> or should we be advertising an RFC 2136 server over HNCP? > I think the plan varies ;-) Yeah, that's what I gathered. > hnetd (and current HNCP + my expired autoconf draft) are based on the > idea of using mDNS _and/or stateful DHCPv4 and/or stateful DHCPv6 to > determine what’s on each link, Quoting Stephen: I agree with you as well, initially odhcpd did only do RAs and stateless DHCPv6 however the user community liked their stateful (v4isms) all too much so I had to give in. ;) -- https://github.com/sbyx/odhcpd/issues/55 > Ted’s draft proposes either learn-from-mDNS (=proxy DNS-update) and/or > (manually/automatically configured client-sourced) DNS-update > scheme. I am worried about zone merging + conflict resolution, although > if it works out it sounds like a good solution. > (Zone merging + plain hybrid proxy is at least very problematic, if you > want hybrid proxies to remain stateless. I have looked at it and it is > neither pretty nor efficient.) I haven't looked at it, but my instinct would be to agree with you -- proxying in the presence of merging sounds like a can of worms that we don't want to open. Do any of the Wise People on this list have opinions about RFC 2136? -- Juliusz _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
