Re: [dnssd] SRP: Name Conflicts Handling

[Ted Lemon <[e-mail]>]

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 <[e-mail]> 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?
> 
>> On Fri, Jan 22, 2021 at 10:52 PM Ted Lemon <[e-mail]> wrote:
>> I think that’s a good description of the solution, yes.
>> 
>>> On Jan 22, 2021, at 1:02 AM, Kangping Dong <[e-mail]> 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
>>>    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 <[e-mail]> wrote:
>>>>> On Jan 21, 2021, at 12:27 AM, Kangping Dong <[e-mail]> 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?
>>>> 
>>