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

[Ted Lemon <[e-mail]>]

Okay, as I dig deeper into this, I'm realizing that things have changed /a
lot/ since we had this conversation. First of all, for Matter accessories,
name changes by the server are simply unacceptable. So the idea that we're
going to signal back to the SRP client that we changed the name is no
longer really necessary, because we aren't going to change the name. The
current Apple Advertising Proxy implementation never does renaming.

If there is a name conflict, we report it, but we have done a /lot/ of work
to avoid gratuitous name conflicts, and I think that that work is actually
what we should be relying on here. Effectively what we've done is to make
the advertising proxy look more like an authoritative name server, and as
we agreed in the discussion Kangping found, we are never going to do this
when the SRP server is an authoritative name server.

What we've done here is the TSR draft and the SRP replication draft. The
TSR draft prevents gratuitous name conflicts when two advertising proxies
are not doing SRP replication. The SRP replication protocol provides a way
for multiple advertising proxies to sustain a consensus, so that conflicts
don't occur. Between these two drafts (really, between their
implementations) we no longer see renaming happening with our advertising
proxies.

As we move more toward unicast DNSSD as the baseline, with mDNS as the
exception, I think that the likelihood of conflicts will drop further.

My point is, do we really want to add this complexity in SRP? What is the
problem we are trying to solve here? Most of the time, the way names are
chosen is deterministic—the leftmost label in the service instance name is
the same as the leftmost label in the hostname. And so if there is a name
conflict on one, it's going to be on the other as well.

So what I think we should actually do is leave the document the way it is.
Doing what we're talking about here will create a great deal of complexity
in the client and in the server, at a very late stage in the development of
the protocol, with no obvious benefit.

Thoughts?

On Fri, Sep 23, 2022 at 9:27 AM Tim Wicinski <[e-mail]> wrote:

> How about just the name(s) attempted to register with that request
> which are in conflict?
>
> I vote for being explicit on the minimum the SRP registar needs to do.
>
> also, not a chair but write up all the text changes and make sure the WG
> has no issues with that.
>
> On Fri, Sep 23, 2022 at 9:14 AM Ted Lemon <[e-mail]> wrote:
>
>> Okay. I ask because we should be explicit.
>>
>> Chairs, how do you want to approach this? I think this is a WG consensus
>> that I failed to put into the document, but we didn't last call on it, so I
>> don't know that it's _actually_ consensus. Do we need a new WGLC?
>>
>> On Fri, Sep 23, 2022 at 9:12 AM Esko Dijk <[e-mail]>
>> wrote:
>>
>>> > 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
>>>
>>>
>>>
>>> I think it should respond at least with the names that it knows are in
>>> conflict (based on its internal database of SRP registrations for example).
>>> So, 0 or more records in the response.  Zero records is our current
>>> specified baseline.
>>>
>>> An SRP registrar implementation that wants to put in more work can
>>> certainly do so – we don’t need to standardize here exactly what it should
>>> do for that.
>>>
>>>
>>>
>>> Esko
>>>
>>>
>>>
>>> *From:* Ted Lemon <[e-mail]>
>>> *Sent:* Friday, September 23, 2022 14:56
>>> *To:* Esko Dijk <[e-mail]>
>>> *Cc:* Kangping Dong <[e-mail]>; Tim Wicinski <
>>> [e-mail]>; [e-mail]
>>> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
>>> conflicts
>>>
>>>
>>>
>>> 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
>>>
>>>