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

[Ted Lemon <[e-mail]>]

Yes, that’s the correct behavior.

On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri <[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]> 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]> 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]> 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]> wrote:
>>
>> Hm, you're right, that's never stated explicitly.
>>
>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <[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]> 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]>
>>> 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]> 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]> 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]> 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
>>>>
>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <[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]>
>>>>> 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]> 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]>
>>>>>> 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]> 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
>>>>>>>
>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <[e-mail]> wrote:
>>>>>>>
>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <
>>>>>>>> [e-mail]> wrote:
>>>>>>>>
>>>>>>>>> Ted Lemon <[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]
>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> dnssd mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> dnssd mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>
>>>>
>>>> _______________________________________________
>>>> dnssd mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>
>>>>
>>>> _______________________________________________
>>>> dnssd mailing list
>>>> [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
>>>
>>>
>>>
>>
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>>
>>
>