> On 25 Apr 2016, at 03:39, Ted Lemon <[email protected]> wrote: > > On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek > <[email protected] <mailto:[email protected]>> > wrote: > > 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. > > I'd be grateful if you could expand on that. Why can't we define a way > for clients to do DDNS? > > We can and should. The problem is that we won't see that code ship in new > devices anytime soon, so we still have to make mDNS work.
And this is why the dnssd WG is focused on making mDNS work on multi-subnet networks. But Ted has raised the question of DNS Update there, and we agreed in BA that we’d accept a draft on issues around coexistence of mDNS and DNS Update. > > Just 2136 isn't enfough, because there's no authentication scheme, > > I don't understand this argument. How is non-secured DDNS any less secure > than mDNS? What am I missing? > > This is an implementation issue, not a security issue--sorry for not making > that clear. In order to preserve the same security characteristics that > mDNS has, we have to ensure that the update actually originated on the local > link, which requires a different sort of listener than is present in a > typical DNS server. And existing DNS servers typically don't have any way > to support unauthenticated updates on a first-come, first-served basis, so if > you allow unauthenticated updates, you don't have any way to avoid > collisions. Otherwise you are correct. The answer is to write a document > that describes how to do that, and if you read the homenet naming arch > document, you can see that I actually sketched out a solution there, which I > expect to go in a different document, likely in a different working group. There are many worms in that can :) > Oh, sure, we Poles are not quite as pessimistic as the Finns. I'm > actually of a divided mind here -- I rather like distributed solutions > (hence prefer mDNS to DDNS) but dislike proxying. Part of me just wishes > we'd mandate site-local multicast and do mDNS over that > > The problem with site-local multicast for mDNS is that multicast isn't a > great solution even on the local wire when that wire is wireless. And, you > have to do modify the client anyway. Indeed; this was discussed early on in the dnssd WG, and not considered for those reasons. > Furthermore, if you consider the mdns hybrid proxy stateless, then you can > have a DNS server that is roughly that stateless too. I think it provides > better service continuity if you are willing to retain some state, but > everything will still work even if you don't, just as the hybrid proxy does. Agreed. Tim > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
