Subject: [dnssd] SRP deletes?

From: Ted Lemon <[email-masked]>
Date: Sat, 24 Aug 2019 15:37:03 -0400

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.

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.

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.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 24 Aug 2019 19:41:51 -0400

Ted Lemon <[email-masked]> 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.

    > 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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Sat, 24 Aug 2019 19:58:54 -0400

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 <[email-masked]> wrote:
> 
>

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 25 Aug 2019 20:46:14 -0400

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 <[email-masked]> wrote:
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Aug 2019 21:04:27 -0400

On Aug 25, 2019, at 20:46, Tom Pusateri <[email-masked]> wrote:
> 
> 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 

Updates only ever get processed on the primary authoritative server. Updates can delete some or all records. So we are free to choose the behavior we want. The question is, what behavior do we want?  :)