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

[Tom Pusateri <[e-mail]>]

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]> 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>
> 
>