Re: [dnssd] SRP deletes?

Eventually, the records (whether directly or through an SRP Proxy) get into an authoritative DNS server. If you want special behavior in response to an RFC 2136 Update at the authoritative, then you’ll need to specify that. Otherwise, the KEY can be deleted along with any of the other records.

Tom

> On Aug 24, 2019, at 7:58 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> I think there’s no need for a delete key operation. The main point is that we don’t want services to show up in dialogs if they aren’t present. 
> 
> Sent from my iPhone
> 
>> On Aug 24, 2019, at 19:41, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>> 
>> 
>> Ted Lemon <mellon@fugue.com> wrote:
>>> I’ve been hacking on an SRP mDNS proxy, and I realized that we didn’t
>>> actually specify a mechanism whereby a service can delete itself when
>>> it goes away.  This means that once an advertisement is present, it
>>> will be present until it expires.
>> 
>> If it's not a cool/useful name, then perhaps, who cares?
>> 
>>> This isn’t how regular mDNS works: with regular mDNS, if the service
>>> isn’t there anymore, it’s not advertised anymore, and indeed if there
>>> is a clean shutdown, mDNSResponder will send a “goodbye” packet to let
>>> any consumers of the service know that it’s not there anymore.   I
>>> don’t really know how often it will be the case that there will be a
>>> clean shutdown in an SRP client, but it seems to me that it’s probably
>>> correct to specify this.
>> 
>> It seems that deleting an entry comes with more security risk that creating
>> them.  But, we have DNSSEC signatures, so it shouldn't be much of a problem.
>> 
>>> What do people think about this?
>> 
>>> Also, at present one of the characteristics of FCFS naming is that KEY
>>> records are kept longer than other records, so that the name can be
>>> held even when the service is not available.   So I’m thinking that a
>>> service delete would generally leave the KEY record alone.
>> 
>> So, delete removes the name, but not the KEY RR, so the name can be reclaimed
>> much easier, and nobody else can take the name until it expires.
>> 
>> Are there two forms of delete then?  One of which deletes the KEY RR so that
>> it can be claimed by another.  Consider replacing the "printer".
>> 
>> If not that, then is there a mechanim where the new "printer" can put itself
>> in line to claim "printer" when the old holder expires. Until then, it is
>> printer-02 or some such?  The point is to facilitate the user who wants it
>> called "printer", but the old device is not quite gone yet.
>> 
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd