Juliusz, the problem is that existing home network devices that do DNS-based service discovery do not support DNS update. They could, but they don't, because we didn't define an easy way for them to do it. Just 2136 isn't enough, because there's no authentication scheme, and name servers typically don't take updates from devices, nor is the default domain on a typical home network actually even under the control of the owner of that network.
The reason for doing mdns snooping is that we have no choice. It's not a great solution. However, I believe it can be done in a way that is clean and works. It will not be stateless, although whether the state needs to be persistent is an interesting question. mDNS isn't actually entirely stateless anyway, FWIW. If you think this is a can of worms you'd rather not open, I can understand that, but Stuart and I have had some pretty good conversations about this, and I remain convinced that we can make it work, so I'd encourage you to see what comes out of that process rather than assuming that the situation is hopeless. On Sat, Apr 23, 2016 at 1:35 PM, Juliusz Chroboczek < [email protected]> wrote: > >> 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 >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
