Re: [dnssd] SRP: Name Conflicts Handling

[Ted Lemon <[e-mail]>]

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