Re: [dnssd] SRP: name conflict while not knowing which name conflicts

[Tim Wicinski <[e-mail]>]

On Fri, Sep 23, 2022 at 4:32 AM Esko Dijk <[e-mail]>
wrote:

> Thanks Kangping,
>
>
>
> It looks like including the conflicting name records in the Additional
> section is a good base solution and also easy to describe in the SRP draft,
> which does not impact the states & procedures of registrar and client.
>
> It’s just additional helpful information the client may use to compose the
> retry Update.  The part about renaming by the registrar, on behalf of the
> client, seems more tricky and may impact states & procedures which were
> just WGLC-reviewed now.
>
>
>
> If we use the Additional section for a YXDomain response, this may require
> a formal update of RFC 2136 (3.8) since DNS Update only allows a server to
> repeat all records in the (error) response or to exclude all records.
>
>
>
> Esko
>
>
>
Esko,

I don't think an update to 2136 is needed here, as section 2.2.3.1
describes the differences with an SRP registrations and 2136 Updates,
but this response should be tested against a DNS update response.

Kangping, I believe this is your workflow description - I pasted it here to
assist in my readings.

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.


https://mailarchive.ietf.org/arch/msg/dnssd/cUJBXN9WXBguPKtTYgPYq4bo4pQ/

Tim