[dnssd] Re: SRP + Advertising Proxy: TTL related questions

[Michael Sweet <[e-mail]>]

Esko,

I think a factory reset that didn't actually reset the device to its original "from the factory" state/configuration and destroy any saved data isn't workable - it might not have network access after the reset and the whole purpose of a factory reset is to start over safely/securely/privately to re-provision, retire/recycle/dispose of, or resell the device.


> On Jul 3, 2025, at 3:26 AM, Esko Dijk <[e-mail]> wrote:
> 
> In this case of a planned factory reset that is a standard or expected step in the process:
>  
>     • the device could store the info about the "old" SRP key persistently such that it survives this planned factory reset;
>     • and then after the planned factory reset retrieve the "old" key and send an SRP update signed with the "old" key to remove the "commissionable" service.
>  But if the factory reset is a true factory reset, no information like this would survive.
> Then, if there's no opportunity to remove the service just before doing the factory reset , then I agree using a shorter-than-usual lease time seems the best solution.
>  In this case we rely on cleanup by timing out of the lease (which may take long if the SRP Registrar decided to make the lease much longer than the requested time by the client).
>  Not sure if this leads to any problems? (If it does, maybe TSR can help to distinguish active "commissionable" services vs stale ones.)
>  Esko
>  From: Jonathan Hui <[e-mail]>
> Sent: woensdag 2 juli 2025 22:59
> To: Esko Dijk <[e-mail]>
> Cc: Ted Lemon <[e-mail]>; Abtin Keshavarzian <[e-mail]>; dnssd <[e-mail]>
> Subject: Re: [dnssd] Re: SRP + Advertising Proxy: TTL related questions
>  I agree that explicitly removing the service is ideal. In the case of Matter, I believe the challenge was that a device in commissioning mode is often factory reset and not afforded the opportunity to remove its commissionable service before doing so.
>  --
> Jonathan Hui
>   On Tue, Jul 1, 2025 at 6:23 AM Esko Dijk <[e-mail]> wrote:
> Ok. I believe the correct way for such a situation is to send an update to remove a DNS-SD service again, using an SRP Update, if the service is no longer available.
> If the client doesn't know in advance when the service is to be removed again, it should base its lease time on other considerations. (Whatever these are: maybe do the same like for its other DNS-SD services if it has any.)
>  The described approach is also brittle: the SRP registrar MAY opt to change the lease time to 4 hours, for example.
>  Esko
>  From: Ted Lemon <[e-mail]>
> Sent: dinsdag 1 juli 2025 15:07
> To: Esko Dijk <[e-mail]>
> Cc: Abtin Keshavarzian <[e-mail]>; dnssd <[e-mail]>
> Subject: Re: SRP + Advertising Proxy: TTL related questions
>  We have noted a use pattern where a device that has not yet been paired advertises its availability for pairing using SRP with a short lease interval, with the hope that the pairing will happen quickly and the short lease will result in that service being removed quickly. We should probably think about whether that makes sense, or whether it's better for the device to simply remove the advertisement when pairing is complete.
>  On 1 Jul 2025, at 14:52, Esko Dijk <[e-mail]> wrote:
>  Hi Abtin,
>  thanks for clarifying the OpenThread configurations and algorithm.
>  Based on RFC 9665 I see quite some implementation freedom on handling TTLs:
>  
>     • TTL value for RR in SRP Update is an advisory to the SRP registration (Section 4)
>         • TTL value SHOULD NOT exceed the lease time (within the SRP Update scope)
>     • function of Lease times and the function of TTLs are completely different (Section 5.1)
>     • TTL value for RR when served in a DNS response (e.g. by Advertising Proxy) MAY exceed the remaining lease time (Section 5.1)
>         • although it's not forbidden to e.g. set the TTL based on remaining lease time, if the implementation sees some benefit in that.
>  So an SRP registrar can modify lease times to regulate the amount of SRP Updates per time unit.  (Basically ignoring the SRP client's requested lease time.)
> And it can choose TTL values to regulate the amount of DNS/mDNS queries being sent to its host per time unit.  (Ignoring the SRP client's suggested TTL.)
>  The SRP registrar going along with an SRP client's suggested TTL, within certain preconfigured min/max limits, also sounds like a feasible default strategy.
>  Now that the SRP registrar has determined TTL in some way, I'd assume that the Advertising Proxy uses exactly these TTL values in its mDNS advertisements.
>  The Advertising Proxy draft can maybe list some sensible defaults for TTL?
> For this I created: https://github.com/dnssd-wg/draft-ietf-dnssd-advertising-proxy/issues/6
>  regards,
> Esko
>   From: Abtin Keshavarzian <[e-mail]>
> Sent: dinsdag 1 april 2025 22:50
> To: Ted Lemon <[e-mail]>
> Cc: Esko Dijk <[e-mail]>; dnssd <[e-mail]>
> Subject: Re: SRP + Advertising Proxy: TTL related questions
>  Let me clarify the statement about OpenThread behavior.
> 
> OpenThread is a network stack designed to run on a variety of platforms and device categories, offering flexibility in configuration and integration into projects and products.
> 
> Regarding the SRP Server and Advertisement Proxy, OpenThread provides several integration options:
> 
> A) Platform/Project Managed: The platform or project handles all SRP Server and Adv Proxy functionalities, making them fully project/product-specific.
> B) OpenThread SRP Server, Platform Adv Proxy: The SRP Server function is implemented within the OpenThread core, while the Advertisement Proxy is delegated to the platform.
> C) OpenThread Native SRP Server and Adv Proxy: Both the SRP Server and the Advertisement Proxy are provided by the OpenThread core.
> 
> The OpenThread SRP server implementation tracks a TTL for each registered service and host:
> 
> - The TTL is set to the minimum of the granted lease time and the TTL from the records in the SRP message. Note that SRP requires TTL consistency, so all RRs within an SRP message must use the same TTL.
> - OpenThread also provides `otSrpServerTtlConfig`, which can be configured via APIs to specify a minimum and maximum TTL range. The granted TTL is then clamped to fall within this defined range.
> - The OpenThread SRP client also offers APIs to explicitly set the desired TTL value if needed. If not explicitly set, the client will use the lease time as the TTL (default value 2 hours).
> 
> Regarding the Advertisement Proxy:
> 
> - For options (A) and (B), the Adv Proxy behavior, including TTL handling, is entirely dependent on the platform implementation. This, I believe, is what Esko's setup is using and what he observed.
> - In option (C), where the OpenThread native Adv Proxy is used, it utilizes the TTL managed by the SRP server as described above.
> - For the Advertisement Proxy, it makes sense to honor the TTL included in the SRP message while adhering to some min/max limits.
> - The default/common behavior would be for the SRP client to set the TTL the same as the lease time (typically 2 hours). If, however, the TTL value is explicitly set to a different value by the SRP client, then it makes sense for this request to be honored by the Advertising proxy.
>  Abtin.
>  On Mon, Mar 31, 2025 at 5:15 AM Ted Lemon <[e-mail]> wrote:
> Actually we’ve learned (because of thread!) that the 120s ttl is way too short, and mDNSResponder now uses a 75 minute ttl for address records. 
>  If the goodbye packet doesn’t come, then the next step is to probe. See for example the DNSServiceReconfirmRecord API. 
>  On Mon, Mar 31, 2025, at 11:19 AM, Esko Dijk wrote:
> > and rely on the goodbye packet to remove the record if the lease expires
>  This works well as long as the SRP Registrar stays online. If it is unexpectedly disconnected, there’s no opportunity to send goodbyes for all its proxied services/host-names.
> I’m guessing that’s why mDNS chose the 120 seconds limit, which feels fairly short but somewhat addresses the issue of a device suddenly being disconnected/powered-off.
>  If we go for “long” TTLs, then we need to define a recommendation for this time. E.g. in the order of 30 minutes?
> Maybe a range can be defined. Then, if there’s a record registered via SRP with a longer lease time (e.g. 8 hours, or 24 hours) then the mDNS advertised TTL can also be initially advertised as longer, up to the high end of this range.
> Say, 2 hours (if that’s the end of the range).
>  Esko
>  From: Ted Lemon <[e-mail]>
> Sent: maandag 31 maart 2025 11:01
> To: Esko Dijk <[e-mail]>; dnssd <[e-mail]>
> Cc: [e-mail]
> Subject: Re: SRP + Advertising Proxy: TTL related questions
>  There is a significant cost to short ttls for mdns: if there is an active query on a record, we will see mdns exchanges towards the end of the ttl to keep the query going. 
>  Given that mdns also has maintenance packets, it’s better to use a long ttl and rely on the goodbye packet to remove the record if the lease expires. 
>  Letting the client choose the mdns ttl could enable a dos attack. 
>  On Mon, Mar 31, 2025, at 10:19 AM, Esko Dijk wrote:
> Hi all,
>  The Advertising Proxy can advertise DNS records using mDNS, where the records were received in an SRP Update. This brings up questions related to the TTL of the mDNS-advertised records.
> mDNS has some standard guidance for TTL (e.g. 2 minutes for host-related records and SRV, 75 minutes for others like TXT). So an implementer could use this guidance. This is what I see in the OpenThread implementation.
>  However, in the SRP + Advertising Proxy case, the registered records each come with their own TTL value that maybe should be respected. So then the mDNS component could use those (received) TTLs and do a countdown on the time.
> For example, if the SRP lease time is 10 minutes, and 4 minutes passed since the last SRP Update, then mDNS will advertise the service (PTR + SRV+ TXT) with a TTL of 6 minutes.
> Would this be the intention for Advertising Proxy?  Or can the defaults be used? 
>  Alternatively there could also be some kind of cap on the mDNS-advertised TTL (like 2 minutes?) to avoid the TTLs on mDNS getting very large. (RFC 6762 kept these fairly small, for a good reason probably).
> In that case the TTLs can be smaller but not larger than the cap.
>  Regards
> Esko
>  _______________________________________________
> dnssd mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> _______________________________________________
> dnssd mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]


________________________
Michael Sweet