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

[Ted Lemon <[e-mail]>]

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-registr
>>> ation/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/Stuart
>>>>>> Cheshire/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
>
>
>