Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt

[Tom Pusateri <[e-mail]>]

Speaking of name changes, you may need to handle name collision in a special way. Since devices can’t see other devices names, they can’t easily create unique names. So if there are 10 light bulbs from the same vendor all starting to register the instance name “light bulb”, the first will succeed and the others get YXDOMAIN. The second one will realize the name is taken but not know how to necessarily create a new name that is unique. The tenth light bulb might go through 9 iterations before generating a unique name. The traditional name collision avoidance mechanism with mDNS of incrementing a numerical suffix doesn’t work very well when you don’t know how many there are.

It might be better to suggest a random suffix instead of a numerical one or some other mechanism of generating unique names from the beginning. But then they won’t look human readable so I don’t know if that is a consideration.

Thanks,
Tom



> On Jul 18, 2018, at 10:30 PM, Ted Lemon <[e-mail]> wrote:
> 
> Depends on how the name change happens, but sure.   If a device has a name-change UI, it could use a very short update lease time, but the server might override it.   I guess we could define an SRP delete message that deletes all or part of a registration.
> 
> On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
> So if a device changes it’s name, the old one could be around for a while along side the new name. 
> 
> That might be confusing. 
> 
> Tom
> 
> On Jul 18, 2018, at 10:06 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> Okay, I've pushed fixes for the last couple of issues you guys brought up.   I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up for debate.
>> 
>> https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11 <https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11>
>> 
>> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>> Yes, that’s the correct behavior. 
>> 
>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>> Yeah, that needs to be more explicit. 
>> 
>> If you try to do a delete, does the server send REFUSED?
>> 
>> Thanks,
>> Tom
>> 
>> On Jul 18, 2018, at 8:27 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> You can't delete anything from a service name.   Maybe we need to say that more explicitly.   Right now the protocol doesn't allow a service to delete itself; only to add itself.   The assumption is that the service will not know in advance that it is leaving the network, so service entries get garbage collected, rather than being explicitly deleted.   Compare to DHCPRELEASE in the DHCP protocol, which is pretty useless.
>>> 
>>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>>> You might not need a new KEY record for the PTR but you may need to follow the instance of the PTR to a KEY record to make sure you have permission to delete the PTR record.
>>> 
>>> Tom
>>> 
>>> 
>>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Tim and I were talking and we were wondering if one client could delete the PTR record for a service instance that another client created? Seems like it’s not protected and could be a denial of service attack? So you might need a KEY record the PTR record.
>>>> 
>>>> Tom
>>>> 
>>>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> Hm, you're right, that's never stated explicitly.
>>>>> 
>>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> I don’t see anywhere in the document where the anycast update method relies on UDP.
>>>>> 
>>>>> Tom
>>>>> 
>>>>> 
>>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> 
>>>>>> Of course, you still have a very good point in that the anycast update method relies on UDP, so sending the key multiple times isn't desirable.   But I also don't see a way around this.   We could have the server replicate the key, I guess.
>>>>>> 
>>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> Just saw this in Section 2: "By requiring the use of TCP, the possibility of off-network spoofing is eliminated”. So requiring TCP is already handled.
>>>>>> 
>>>>>> Searching for _dns-update._udp.<domain> still seems odd but that’s been going on for a while a presume.
>>>>>> 
>>>>>> Tom
>>>>>> 
>>>>>> 
>>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> Looking in the IANA registry, dns-update isn’t assigned for TCP. So either you search for _dns-update._udp.<domain> and use TCP or you register _tcp.
>>>>>>> 
>>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP packet size larger than 512, you probably wouldn’t want to set it larger than the MTU and 1480 isn’t big enough for 3 KEYs plus other records.
>>>>>>> 
>>>>>>> Tom
>>>>>>> 
>>>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>> 
>>>>>>>> If you are adding more KEY records, you will certainly exceed the UDP update size of 512 bytes. The draft doesn’t mention transport but maybe this should be restricted to TCP.
>>>>>>>> The draft does mention searching for the update server using _dns-update._udp.<domain>. But then it won’t be able to use UDP for updates.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Tom
>>>>>>>> 
>>>>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>> 
>>>>>>>>> Tim pointed out that we need to protect the Service Instance Name as well as the Host Description with a KEY record, because FCFS naming has to protect both the service description and the host description.   Here are the changes:
>>>>>>>>> 
>>>>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597 <https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597>
>>>>>>>>> 
>>>>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>> The question of whether we update RFC6763 is basically "is there text that is in RFC6763 that is no longer correct because of this document."  I think the answer is no.
>>>>>>>>> 
>>>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>> Ok, just checking. So given that 6763 semi-defines service registration protocol as DNS Dynamic Update, should this document claim it updates 6763?
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Tom
>>>>>>>>> 
>>>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>> 
>>>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery.   So I tried to harmonize the document toward that—did I miss something?
>>>>>>>>>> 
>>>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>> How is DNS-Based Service Discovery different from DNS Service Discovery?
>>>>>>>>>> 
>>>>>>>>>> Is this meant to distinguish from RFC 6763?
>>>>>>>>>>  
>>>>>>>>>> Thanks,
>>>>>>>>>> Tom
>>>>>>>>>> 
>>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> BTW, the current version of the document on github now includes fixes for all the points that have been raised other than the ones I said I wasn't going to fix: https://github.com/StuartCheshire/draft-sctl-service-registration <https://github.com/StuartCheshire/draft-sctl-service-registration>
>>>>>>>>>>> 
>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>>>> Ted Lemon <[e-mail] <mailto:[e-mail]>> writes:
>>>>>>>>>>> 
>>>>>>>>>>> Why can't it be just a Host Description? Might be useful for a device
>>>>>>>>>>> that just wants to register its name but doesn't (currently, or ever)
>>>>>>>>>>> advertise any services...
>>>>>>>>>>> 
>>>>>>>>>>> Good question.   What does the working group think?   :) 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> dnssd mailing list
>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> dnssd mailing list
>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> dnssd mailing list
>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> dnssd mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> dnssd mailing list
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf...org/mailman/listinfo/dnssd>
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> dnssd mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> dnssd mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
>>> 
>>> 
>> 
> 
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd