[dnssd] Re: SRP: clarification of SRP requester's retry strategy for YXDomain error

[Esko Dijk <[e-mail]>]

Right, I didn’t intend to change something in the SRP draft at this stage – the text there looks correct to me in its scope (which is a single SRP Registrar. It doesn’t consider multiple cooperating ones or non-cooperating ones.)
First I wanted to clarify in that context what “give up” means for the client. At least it means giving up trying to register the name(s) with the same SRP Registrar, in this scope. The case of multiple Registrars seems to be out of scope.

Second was the consideration of clients with fixed (unique) names that are unable to choose new names. In this case a name conflict is either the result of a self-conflict (possibly due to bugs or unforeseen network scenarios), or a real conflict (where one actor attempts to ‘steal identity’ or DoS the true device). In the scope of draft-SRP, the client just has to give up. But in practice it will still try again next time it’s booted up. (And it better – that’s way more robust.)

As Abtin mentioned, for the Thread specification there can be specific workarounds for such issues that are hopefully not breaking the protocol. In this specific context (Thread), also testing is done to build confidence that the workarounds don’t break anything.

Esko

From: Abtin Keshavarzian <[e-mail]>
Sent: vrijdag 4 april 2025 20:34
To: Ted Lemon <[e-mail]>
Cc: [e-mail]; Esko Dijk <[e-mail]>; Stuart Cheshire <[e-mail]>
Subject: Re: [dnssd] SRP: clarification of SRP requester's retry strategy for YXDomain error


I agree that updating the SRP RFC document on the IETF track to add new behavior doesn't seem necessary. The SRP RFC can continue to state what it already does. I also doubt Esko intended to suggest changing the SRP RFC.

The Thread specification adopts solutions from various standards and sources, adding clarifications that may relax or update certain aspects. In line with this, the Thread specification is the appropriate place to add clarification regarding SRP retries.

Regarding TSR, while I haven't delved deeply into it, I agree it generally seems like a viable approach to address many self-induced conflict errors in the Advertising Proxy. TSR is a good example of solving a problem created by earlier design choices (ideally, such considerations would have been part of the original Adv Proxy and SRP designs). TSR should be viewed as a solution for the future and I wouldn't consider it a mature solution at this point. It appears to be still evolving. I've noticed changes in the text whenever I've reviewed the text and I understand it was only recently accepted by the IETF working group.

We must also note that Thread Border Routers following the current SRP and Adv Proxy specifications are already deployed (by various vendors using OpenThread or their custom implementations). It's crucial that Thread devices running the SRP client remain compatible with these existing Thread BRs.

On Fri, Apr 4, 2025 at 3:24 AM Ted Lemon <[e-mail]<mailto:[e-mail]>> wrote:
I think we let this drop, but I'd like to get to a conclusion. The current SRP document says that if you get a YXDOMAIN, you have to give up or choose a different name. Abtin pointed out that with an advertising proxy, it's possible that the YXDOMAIN could be due to there being two non-cooperating advertising proxies, and that in this case it makes sense for the client to try the next advertising proxy.

I would like to first state that although I understand Abtin's point, I don't think this is the right way to solve the problem. This is one very specific situation, which is completely addressed by TSR: in the case that the advertising proxy implements TSR, this scenario cannot happen. So we are only addressing a very specific use case here: multiple non-cooperating advertising proxies that do not implement TSR. In any other situation, the retry is incorrect behavior. On a constrained network, it's expensive incorrect behavior.

So I certainly do not thin that we should codify this behavior in the soon-to-be-published SRP document as an AUTH48 change. This is behavior that was never discussed by the working group, and that's generally contrary to how DNS works in the real world. In the real world, SRP updates update authoritative DNS servers, and authoritative DNS services are a single source of truth. The problem here is that mDNS is not DNS. We've come up with two ways to address the shortcomings of mDNS with respect to SRP, neither of which involves changing DNS protocol behavior.

To dig into this objection a bit more, in order to correctly specify some new behavior for YXDOMAIN, we would have to specify something like section 4.6 of RFC2136. But that says that when we get an adverse response, we delete the responding server from our list of servers to attempt to update. The reason for doing this is so that we don't cycle back to it later. But we don't have that option here. So specifying this behavior in detail is actually a fairly significant job, and not something that I think makes sense to do in AUTH48, even if it were the right thing to do.

Given that we have two fairly mature solutions to this problem—SRP replication and TSR—I think adding a third solution is not a good idea.


On 28 Mar 2025, at 20:14, Ted Lemon <[e-mail]<mailto:[e-mail]>> wrote:

You're right, if you set things up this way then it makes sense for the client to try the next server. The latest advertising proxy draft discourages returning YXDOMAIN in this case, and the Apple implementation no longer does this. We use replication, so it's a bit different, but even without replication, if you have TSR, you won't get a conflict in this situation, because the stale data on the other server will be flushed when the new data is announced.


On 28 Mar 2025, at 19:25, Abtin Keshavarzian <[e-mail]<mailto:[e-mail]>> wrote:

> No, this doesn't make sense. If the name is in use, the name is in use. Trying a different registrar isn't going to make things better. It might make things worse, though: if the name has been claimed on one registrar, but not the other, and both are acting as advertising proxies, then registering with the second registrar will crreate an mDNS name conflict, which is an additional mess and an additional performance hit. There's no good outcome to re-registering when you get a YXDOMAIN response—you need to choose a new name.

I disagree. This can indeed be useful.

Example scenario:

- Two (or more) Thread Border Routers acting as SRP servers (registrars).
- A device successfully registers with one with a long lease and key-lease.
- While its lease/key-lease is still valid, the device is rebooted and becomes offline.
- Later, the device comes back online but now happens to choose/prefer the other BR (registrar) to register with.
- This creates a name conflict as the name is still claimed by the other BR (registrar), and the device receives an NXDOMAIN response.
- Upon this, the device switches to the other BR (registrar), which now succeeds.

Ted, you did explain the situation but seem to miss this.

For the record, this situation has been observed in the testing (of Matter/Thread), and this mechanism (switch server) was added in the OpenThread implementation since 2021 and has been well-tested and deployed.

Abtin.

On Fri, Mar 28, 2025 at 7:38 AM Ted Lemon <[e-mail]<mailto:[e-mail]>> wrote:
On 28 Mar 2025, at 13:24, Esko Dijk <[e-mail]<mailto:[e-mail]>> wrote:
From the SRP draft -27 section 3.2.5.2 on name conflicts:

   … the registrar will respond to the SRP Update with a YXDomain RCODE [RFC2136]. In this case, the SRP requester MUST choose a new name or give up.

Some discussion came up on this:


  1.  In a network with multiple SRP Registrars, the SRP requester could also retry the SRP Update at another SRP Registrar if one fails.  I assume this does not violate the MUST requirement as long as it does not retry with the same SRP registrar. I.e. “give up” means giving up the registration with that name for this particular SRP Registrar. OpenThread for example implements retry with another Registrar.  It could happen that this other Registrar accepts the SRP Update.  Any disagreement on this interpretation?

No, this doesn't make sense. If the name is in use, the name is in use. Trying a different registrar isn't going to make things better. It might make things worse, though: if the name has been claimed on one registrar, but not the other, and both are acting as advertising proxies, then registering with the second registrar will crreate an mDNS name conflict, which is an additional mess and an additional performance hit. There's no good outcome to re-registering when you get a YXDOMAIN response—you need to choose a new name.



  1.  Choose a new name: some application layers (Matter) specify particular names to be used, so won’t be able to support selecting a new name.  In this case, the SRP requester would give up presumably. However, because SRP Updates have a limited lifetime, it’s still worth retrying the registration later on e.g. some hours or days later. Any opinions on this? That’s not strictly a “give up” action but seems reasonable to do.   E.g. there could be a lingering SRP registration causing the conflict, or a device temporarily trolling (by snatching a device’s unique name) at an mDNS link. Such situation may be resolved some hours later.

In the case of Matter, the names are guaranteed unique. So if we get a name conflict, something weird is happening. Trying to write code that adapts to this is unlikely to succeed, but I agree that waiting a bit and trying again is harmless, and could help. It would be better to understand how such a name conflict occurred and address that situation. E.g., if the conflict occurs because the device has a Thread and a WiFi interface and advertises the same name on both interfaces, then it's quite likely that the SRP server will get a name conflict when it tries to advertise the name with mDNS. In this situation, it might return a name conflict error (although the Apple implementation no longer does this). So this is actually a protocol problem we need to solve, and re-attempting the registration later, while it might happen to work, isn't doing that.


_______________________________________________
dnssd mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

_______________________________________________
dnssd mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>