Re: [dnssd] SRP: Name Conflicts Handling

[Kangping Dong <[e-mail]>]

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

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