Re: [dnssd] SRP: Name Conflicts Handling

[Kangping Dong <[e-mail]>]

Hi Ted,

Sorry for the late reply.

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.
>
Agree.

 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.

Option (1) also looks good to me. But what are the RRs that should be
included in the response? SRV RR for service instance name and AAAA/A RR
for host name?


BRs,
Kangping

On Mon, Jan 18, 2021 at 10:21 PM Ted Lemon <[e-mail]> wrote:

> 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:
>
>
>    1. 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.
>    2. 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.
>    3. 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?
>
>