Subject: [dnssd] SRP: Name Conflicts Handling

From: Kangping Dong <[email-masked]>
Date: Fri, 15 Jan 2021 14:03:14 +0800

Hi DNSSD enthusiasts,

For Service Registration Protocol (SRP), when a SRP server receives a
registration with names
that have already been taken by another client, it responds with a YXDOMAIN
error code to indicate
name conflicts. When the client receives such a response, it typically will
re-generate a new host or
service instance name and re-register with the new name.

The problem is that a typical SRP update will include one Host Description
Instruction and one (or more)
Service Description Instructions (zero Service Description Instruction is
allowed but it is more common
that the client registers the host with some service instances). Name
conflicts can happen on both Host
Description instruction and Service Description Instruction, but there is
no description of how to tell the
client which instruction includes the conflict (or both include conflicts).
Currently, the client needs to re-new
both host name and service instance name or re-new a single name and starts
a trial-and-error process
until it finally succeeds.

One solution is, the server/registry responds with the *Instruction(s)* which
has name conflicts. For the
client, it should check the RRs in the response to get the conflicting name
if a YXDOMAIN response
code is received. To Reduce data transported between the server & client,
the server may just include
one RR, but not the entire *Instruction*, that contains the conflicting
name.

Thoughts?

BRs,
Kangping

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Jan 2021 09:30:02 -0500

How about including an additional section on the response that includes the conflicted names and rrtypes with zero length data? Or just pointing to the root?

> On Jan 15, 2021, at 01:03, Kangping Dong <[email-masked]> wrote:
> 
> 
> Hi DNSSD enthusiasts,
> 
> For Service Registration Protocol (SRP), when a SRP server receives a registration with names
> that have already been taken by another client, it responds with a YXDOMAIN error code to indicate
> name conflicts. When the client receives such a response, it typically will re-generate a new host or
> The problem is that a typical SRP update will include one Host Description Instruction and one (or more)
> Service Description Instructions (zero Service Description Instruction is allowed but it is more common
> that the client registers the host with some service instances). Name conflicts can happen on both Host
> Description instruction and Service Description Instruction, but there is no description of how to tell the
> client which instruction includes the conflict (or both include conflicts). Currently, the client needs to re-new
> both host name and service instance name or re-new a single name and starts a trial-and-error process
> One solution is, the server/registry responds with the Instruction(s) which has name conflicts. For the
> client, it should check the RRs in the response to get the conflicting name if a YXDOMAIN response
> code is received. To Reduce data transported between the server & client, the server may just include
> one RR, but not the entire Instruction, that contains the conflicting name.
> 
> Thoughts?
> 
> 
> BRs,
> Kangping
>

---

From: Kangping Dong <[email-masked]>
Date: Mon, 18 Jan 2021 11:45:32 +0800

Should we use one RR with ANY type (and zero rdata) for one conflicted
name? Because the conflict applies to all RRs of this name.

Or just pointing to the root?
Sorry, I am not following. Do you mean including exactly the original RR
that has name conflict?

BRs,
Kangping

On Fri, Jan 15, 2021 at 10:30 PM Ted Lemon <[email-masked]> wrote:

> How about including an additional section on the response that includes
> the conflicted names and rrtypes with zero length data? Or just pointing to
> the root?
>
> client which instruction includes the conflict (or both include
> conflicts). Currently, the client needs to re-new

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Jan 2021 23:08:12 -0500

The ptr or srv record, yes. I don’t think any is allowed outside of the question section. 

> On Jan 17, 2021, at 22:46, Kangping Dong <[email-masked]> wrote:
> 
> 
> Should we use one RR with ANY type (and zero rdata) for one conflicted name? Because the conflict applies to all RRs of this name.
> 
> Sorry, I am not following. Do you mean including exactly the original RR that has name conflict?
> 
> 
> BRs,
> Kangping
>

---

From: Kangping Dong <[email-masked]>
Date: Mon, 18 Jan 2021 15:05:33 +0800

Thanks, then I think both zero rdata and original rdata work for me.

BRs,
Kangping

On Mon, Jan 18, 2021 at 12:08 PM Ted Lemon <[email-masked]> wrote:

>> The problem is that a typical SRP update will include one Host
>> Description Instruction and one (or more)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jan 2021 09:21:47 -0500

> 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?

---

From: Kangping Dong <[email-masked]>
Date: Thu, 21 Jan 2021 13:27:51 +0800

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

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Jan 2021 11:11:14 -0500

On Jan 21, 2021, at 12:27 AM, Kangping Dong <[email-masked]> wrote:
> 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?

Yes, I think that makes sense. These unambiguously indicate what type of update failed. Which brings up the question of what RRtype to use for renaming. CNAME?

---

From: Kangping Dong <[email-masked]>
Date: Fri, 22 Jan 2021 14:02:07 +0800

To make sure if I correctly understand how this works, let me explain how a
SRP client will handle name conflicts:
1. If a name has already been registered on the SRP server or a name
conflict error is returned by the Advertising Proxy:
    the SRP server responds with the RR that includes the conflicted name.
If the client sees such records, it knows the conflicts
   on the SRP server and will retry with a new name.
2. If a name conflict is reported to the SRP server after the SRP update
transaction has been committed:
    The next time the SRP client registers, the SRP server responds
with a CNAME record which includes the new name.
    If the client sees such records, it knows the conflict on the multicast
link and will accept the name or retry with another name.

Am I correct about the workflow?

On Fri, Jan 22, 2021 at 12:11 AM Ted Lemon <[email-masked]> wrote:

> Yes, I think that makes sense. These unambiguously indicate what type of
> update failed. Which brings up the question of what RRtype to use for
> renaming. CNAME?
>
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Jan 2021 09:52:38 -0500

I think that’s a good description of the solution, yes.

> On Jan 22, 2021, at 1:02 AM, Kangping Dong <[email-masked]> wrote:
> 
> To make sure if I correctly understand how this works, let me explain how a SRP client will handle name conflicts:
> 1. If a name has already been registered on the SRP server or a name conflict error is returned by the Advertising Proxy:
>     the SRP server responds with the RR that includes the conflicted name. If the client sees such records, it knows the conflicts
> 2. If a name conflict is reported to the SRP server after the SRP update transaction has been committed:
>     The next time the SRP client registers, the SRP server responds with a CNAME record which includes the new name.
>     If the client sees such records, it knows the conflict on the multicast link and will accept the name or retry with another name.
> 
> On Fri, Jan 22, 2021 at 12:11 AM Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
> On Jan 21, 2021, at 12:27 AM, Kangping Dong <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Kangping Dong <[email-masked]>
Date: Sun, 24 Jan 2021 14:04:53 +0800

okay, the workflow almost works for me, just a small question. For case 2,
when the Advertising Proxy detects a name conflict on the multicast link,
it choses a new name and informs the SRP server the new name. Before the
client refreshes its service registration, how should the SRP server/Border
Router
respond to a DNS query for the original name? I think the BR will reject
the query with some error like *RESOURCE_NOT_FOUND* / *NAME_NOT_FOUND*, as
the
service has already been renamed but just the client hasn't
been notified yet. right?

On Fri, Jan 22, 2021 at 10:52 PM Ted Lemon <[email-masked]> wrote:

>     If the client sees such records, it knows the conflict on the
> multicast link and will accept the name or retry with another name.
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Jan 2021 10:58:56 -0500

If there is a name conflict, it’s because the name is in use. This will never happen if the srp server is an authoritative name server: in this case there is only one source of truth.

It will only happen if the underlying service is an unauthenticated distributed service like mDNS. So in this case we rely on the definition of that service to say what will be done. I believe this is discussed in rfc 6762 for mDNS. 

> On Jan 24, 2021, at 01:05, Kangping Dong <[email-masked]> wrote:
> 
> 
> okay, the workflow almost works for me, just a small question. For case 2, when the Advertising Proxy detects a name conflict on the multicast link,
> it choses a new name and informs the SRP server the new name. Before the client refreshes its service registration, how should the SRP server/Border Router
> respond to a DNS query for the original name? I think the BR will reject the query with some error like RESOURCE_NOT_FOUND / NAME_NOT_FOUND, as the
> service has already been renamed but just the client hasn't been notified yet. right?
>

---

From: Kangping Dong <[email-masked]>
Date: Tue, 26 Jan 2021 11:22:22 +0800

Makes sense, Thanks!

On Sun, Jan 24, 2021 at 11:58 PM Ted Lemon <[email-masked]> wrote:

> If there is a name conflict, it’s because the name is in use. This will
> never happen if the srp server is an authoritative name server: in this
> case there is only one source of truth.
>
> It will only happen if the underlying service is an unauthenticated
> distributed service like mDNS. So in this case we rely on the definition of
> that service to say what will be done. I believe this is discussed in rfc
> 6762 for mDNS.
>
> the query with some error like *RESOURCE_NOT_FOUND* / *NAME_NOT_FOUND*,
> as the
>>     the SRP server responds with the RR that includes the conflicted
>> name. If the client sees such records, it knows the conflicts