Re: [dnssd] SRP: Name Conflicts Handling

[Ted Lemon <[e-mail]>]

On Jan 18, 2021, at 2:05 AM, Kangping Dong <[e-mail]> wrote:
> Thanks, then I think both zero rdata and original rdata work for me.

Okay. I think it’s better if the response is syntactically valid to a parser that doesn’t have special knowledge, so we shouldn’t use zero-length rdata. We could encode some information in the CLASS or TTL of the response, though. One thing that occurs to me is that there’s a failure mode that can occur if you are using an advertising proxy (as opposed to an authoritative server) model: two different clients choose the same name at roughly the same time, but their advertising proxies aren’t in communication, so duplicate detection fails to detect the conflict before a positive reply is sent to both.

Later on, the conflict is noticed, and one or both of these devices gets renamed. At this point we don’t have a way to communicate the name change to the SRP client, because it’s not expecting another reply. For SRP clients that make TCP connections to the server, we could use some sort of subscription model to address this, but for constrained clients (e.g. Thread accessories), that won’t work. There are three ways to address this problem that have occurred to me:

The next time the SRP client registers, we signal to it that it was renamed, and give it its new name. The SRP client is then free to either register another name, or accept the new name that it was given.
The next time the client registers, we signal to it that there is a name conflict, and it renames itself; the temporary new name is removed.
The SRP server just carries on with the new name without notifying the client.

Right now, my advertising proxy implementation does (3). The reason is that this produces the fewest name changes, and that seemed like a desirable characteristic. I did this because the only simple alternative that occurred to me at the time was (2), which would always result in the client being renamed twice. 

However, since we are now contemplating sending back conflict information, (1) becomes possible—we can send back the name that was rejected, and the new name, marking the rejected name with a TTL of zero and the new name with a TTL that is nonzero. This gives the client the option to choose a new name if there is a conflict. It doesn’t have to choose a new name—it can do nothing. So now we have full transparency, and the correct amount of efficiency.

What do you think of these approaches?