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

[Ted Lemon <[e-mail]>]

RFC 2136 has some specific language here, so we can mostly refer to that,
but I think to address your concern we should explicitly say that any
records sent in the response should be silently ignored. We can specify
some additional behavior in a follow-on document if it makes sense.

Op ma 26 sep. 2022 om 10:50 schreef Ted Lemon <[e-mail]>

> Maybe we should write some conformance tests that send unknown options. :)
>
> But yes, I think you’re right.
>
> Op ma 26 sep. 2022 om 10:49 schreef Esko Dijk <[e-mail]
> >
>
>> Hi Ted,
>>
>>
>>
>> I would still be in favor to insert a sentence about the possible use of
>> the answer records (in case of an error) in the future.
>>
>>
>>
>> > But right now we have no text at all about how the client interprets
>> rrs in the response, so I think even this is unnecessary. If it does
>> something with them, it’s out of spec.
>>
>>
>>
>> In my years of experience with how software development works, an
>> implementer somewhere is bound to check incoming messages very precisely
>> against what the implementer thinks it should be -- never mind the spec.
>> The robustness principle isn’t automatically applied, now in times of
>> security breaches everywhere. It’s rather becoming “if the input looks
>> slightly different from the usual, it must be wrong” and extra checks are
>> coded in everywhere without thinking about extendibility.  I have seen
>> implementations where nice TLVs are defined for extendability, and then
>> Version 1 implementations discard any message received with an unknown TLV
>> type, such that the future Version 2 implementations could never use a new
>> TLV type anymore, i.e. the extendibility that was defined doesn’t exist
>> anymore in practice.
>>
>>
>>
>> Especially in our case  since the base spec DNS Update precisely tells
>> what the response fields can be, we have to say here that SRP deviates:
>> that it can contain something else. (Which is then defined in the future,
>> maybe, or maybe not.)
>>
>>
>>
>> But if the rest disagrees for good reasons then we should not add any
>> text.  This additional text would have zero code impact.
>>
>>
>>
>> Esko
>>
>>
>>
>> *From:* Ted Lemon <[e-mail]>
>> *Sent:* Friday, September 23, 2022 18:47
>> *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
>>
>>
>>
>> I just have no idea what problem you are solving here. And no, we do not
>> know how to represent this in the response.
>>
>>
>>
>> I get that you have some ideas about how this could be used, but that’s
>> not what I’m asking. What I’m asking is, what /problem/ does this solve?
>> What bad thing happens if we don’t do this, and how does doing this make it
>> better? And to be clear, by “problem” I mean “what bad experience will the
>> user have that will be less bad if we do this?” Having to rename at all is
>> a catastrophe. We might make that catastrophe trivially smaller. How does
>> that materially benefit the end user?
>>
>>
>>
>> As for representation, right now the response can contain the update,
>> verbatim. We need to specify in detail a response format that the client
>> can unambiguously interpret as listing names that were in conflict. I’m not
>> saying this is hard, just that we have to write it up, implement it, test
>> it, feel confident it works.
>>
>>
>>
>> What we have in the document now describes what we have implemented and
>> extensively interop tested. To meet that standard for this proposed update
>> is at least a year of work.
>>
>>
>>
>> So if we want to do this in this document, we need a really, REALLY, good
>> reason, not some ideas about how it could be used.
>>
>>
>>
>> But the bottom line is that this is harmless. If it’s useful to do this
>> year’s work, let’s just do it in a follow-on document. But I really
>> strongly urge you not to insist on doing it in this document. It’s not as
>> small a change as you are imagining.
>>
>>
>>
>> Regarding preparing the client for this, the new spec would say how the
>> client should handle this, so I don’t think that’s necessary. An existing
>> client can be expected to ignore whatever is sent by a new implementation.
>>
>>
>>
>> I guess we could say that the client MUST ignore any RRs in the response.
>> But right now we have no text at all about how the client interprets rrs in
>> the response, so I think even this is unnecessary. If it does something
>> with them, it’s out of spec.
>>
>>
>>
>> Op vr 23 sep. 2022 om 11:42 schreef Esko Dijk <
>> [e-mail]>
>>
>> > It took you ten paragraphs to explain what the client would do with
>> this information
>>
>> That was just explaining the benefits. Hence the more, the better. It’s
>> just a perfect solution if you just want to be prepared for all possible
>> futures with a minimum of effort and no nasty dependencies. It’s the
>> equivalent of our local high school recommending yesterday for pupils to
>> take the “STEM” profile in case they don’t know yet what future job to do
>> because it leaves a maximum of options still open.  Only, less difficult to
>> execute ;-)
>>
>>
>>
>> But we can also do without solving this particular issue and avoid
>> another WGLC – because we do have simple name-change solutions for the SRP
>> client that work already (as you also indicated).  So if we foresee
>> potential issues/complexity here maybe better leave it for a later time.
>>
>>
>>
>> About the format definition: we already know how to include records into
>> a DNS response so don’t agree to your point there. But true, it will take
>> more than 1 sentence to explain such a new feature – maybe an entire
>> subsection to do it right.
>>
>>
>>
>> Can’t we just say the SRP client MUST be prepared to receive something in
>> Additional records of YXDomain, whatever it is? Just to pave the way for
>> our potential future new draft. (Otherwise the SRP client may ignore the
>> response as “invalid” and not heed it.)
>>
>> That would only be one sentence and requires no code.
>>
>>
>>
>> Regards
>>
>> Esko
>>
>>
>>
>> *From:* Ted Lemon <[e-mail]>
>> *Sent:* Friday, September 23, 2022 17:14
>> *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
>>
>>
>>
>> Eskimo, I beg to differ on the idea that this change is simple. It took
>> you ten paragraphs to explain what the client would do with this
>> information. We don’t know how to encode it in the response, so we have to
>> invent that. We don’t have any implementations of it. So its a really big
>> deal to suggest this change now, after WGLC. If this is important, I think
>> someone who is interested should write up a draft proposing a solution and
>> ask the WG to adopt it.
>>
>>
>>
>> Adding this to SRP now will mean that SRP standardization will take about
>> an additional year, if we move very fast. I don’t think this is remotely
>> worth it.
>>
>>
>>
>> Op vr 23 sep. 2022 om 10:24 schreef Esso Dijk <
>> [e-mail]>
>>
>> Fully agree that we should not do the “renaming by the registrar” part.
>> There’s some additional complexity implied by this and things that may
>> break interoperability.
>>
>>
>>
>> > the leftmost label in the service instance name is the same as the
>> leftmost label in the hostname
>>
>> This is how some implementations may work, but there’s many others that
>> don’t. So we can’t make generic assumptions on naming choices.
>>
>> In any case a smart SRP client that picks its names like this will simply
>> rename both – no additional complexity for the client then.
>>
>>
>>
>> Despite this, it is fairly simple if we say the SRP registrar SHOULD
>> insert any conflicting record(s) that it knows about into the response. As
>> I argued before, this doesn’t change any of the procedures we have defined
>> in SRP so far.
>>
>>
>>
>> And it leaves a great amount of freedom to implementations without
>> apparent disadvantages, and without interop problems:
>>
>>    - A SRP client that doesn’t want to bother parsing the SRP Update
>>    response, can just ignore the Additional records in the YXDomain response.
>>    It can apply its strategy of “change both names” for example as discussed
>>    above.
>>    - An SRP registrar that is on a constrained device, or just doesn’t
>>    want to bother, can include 0 Additional records (equivalent to saying “I
>>    don’t know what the conflict is”) which is acceptable too.
>>    - An SRP registrar that is an existing implementation that people
>>    don’t want to change, is still compliant.
>>    - An SRP client that is an existing implementation that people don’t
>>    want to change, is still compliant.  (Maybe it takes some more retries to
>>    get registered – but that’s no big problem.)
>>    - If in the future an SRP client gets upgraded to a “smarter” client
>>    that can detect the conflicts enlisted in the YXDomain response, it may
>>    become more efficient. This upgrading is independent of servers’ upgrading
>>    or not.
>>    - If in the future an SRP server gets upgraded to a “smarter” server
>>    that can returns conflicts in the YXDomain response, things may become more
>>    efficient. This upgrading is independent from clients’ upgrading or not.
>>    - If the Matter approach to names wins and conflicts hardly occur for
>>    this reason, and hence no-one implements the conflicting-records feature,
>>    then nothing is lost – we just have a small bit of junk-DNA like text in
>>    the SRP RFC.
>>
>>
>>
>> So the idea is to recommend returning known-conflict records FYI to the
>> client and leaving the client free to pursue any naming strategy.
>>
>>
>>
>> Esko
>>
>>
>>
>>
>>
>>
>>
>> *From:* Ted Lemon <[e-mail]>
>> *Sent:* Friday, September 23, 2022 15:59
>> *To:* Tim Wicinski <[e-mail]>
>> *Cc:* Esko Dijk <[e-mail]>; Kangping Dong <
>> [e-mail]>; [e-mail]
>> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
>> conflicts
>>
>>
>>
>> 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
>>
>>