Re: [dnssd] SRP: Name Conflicts Handling

[Kangping Dong <[e-mail]>]

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