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

[Esko Dijk <[e-mail]>]

Hi Tim,

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

Clear, we can just add a bullet in 2.2.3.1 then as plain DNS Update isn’t updated by this draft.  What’s important then is that the server, when receiving a DNS Update that is not an SRP Update, will not use the new mechanism of including the conflicting record(s). Only do this for an SRP Update.
And for testing: do you mean sending the “new” type of YXDomain response to a plain DNS Update client and see what happens?  That seems not necessary if the SRP registrar is careful in using the “new” response format only for SRP clients.

Esko


From: Tim Wicinski <[e-mail]>
Sent: Friday, September 23, 2022 12:28
To: Esko Dijk <[e-mail]>
Cc: Kangping Dong <[e-mail]>; [e-mail]; Ted Lemon <[e-mail]>
Subject: Re: [dnssd] SRP: name conflict while not knowing which name conflicts



On Fri, Sep 23, 2022 at 4:32 AM Esko Dijk <[e-mail]<mailto:[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