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

[Ted Lemon <[e-mail]>]

Aargh. Thanks for catching this Eskimo, and thanks Kangping for remembering
the conversation. I had completely forgotten, although I recall it now of
course.

One problem with this approach is that it will not be the case that the SRP
server necessarily knows all of the names that are in conflict. So it can
certainly respond with a list of the names on which it found conflicts, but
the list might not be able to be made complete without more work. Do we
want to require it to do that work?

Op vr 23 sep. 2022 om 08:07 schreef 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]>
> 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
>