Re: [homenet] Updating DNS [was: How many people have installed the homenet code?]

["Ray Hunter (v6ops)" <[e-mail]>]

Tim Chown wrote:
>> On 25 Apr 2016, at 03:39, Ted Lemon <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> On Sun, Apr 24, 2016 at 12:29 PM, Juliusz Chroboczek 
>> <[e-mail] 
>> <mailto:[e-mail]>> 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.
That to me seems to be putting pragmatism before requirements.

I'm not entirely convinced by the dnssd work, and have said so on the 
relevant WG.
>
> 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.
If "it" (multi-subnet mDNS) is going to cause more issues down the line, 
is it sensible to pull this into Homenet now?

Is that the intended question to be answered by that draft?
>
>>     > 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 :)
I understand that this is potentially a huge can of worms, but if no one 
opens it, it'll never get solved.

So my preference would be to write down what we want in Homenet (in the 
naming architecture document, in a technology-agnostic way), analyse the 
gaps against competing current technologies, and then see what people 
propose to close those gaps.

If multi-subnet mDNS comes out a clear winner, then I'll shut up.

But I'm not even convinced that the gaps are understood/ documented at 
this time.

>
>>     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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>