Re: [dnssd] SRP: Name Conflicts Handling

[Ted Lemon <[e-mail]>]

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 <[e-mail]> 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
> 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
>