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

[Ted Lemon <[e-mail]>]

I've updated section 2.3.5 as follows:

           <t>
-           The status that is returned depends on the result of processing
the update, and can be either NoError or ServFail: all
+           The status that is returned depends on the result of processing
the update, and can be either NoError, ServFail, Refused or YXDomain: all
            other possible outcomes should already have been accounted for
when applying the constraints that qualify the update
-           as an SRP Update.</t>
+           as an SRP Update. The meanings of these responses are explained
in <xref target="RFC2136" section="2.2"/>.</t>
+         <t>
+           In the case of a response other than NoError, <xref
target="RFC2136" section="3.8"/> specifies that the server is permitted
+            to respond either with no RRs or to copy the RRs sent by the
client into the response. The SRP Requestor MUST NOT attempt
+           to validate any RRs that are included in the response. It is
possible that a future SRP extension may include per-RR
+           indications as to why the update failed, but at present this is
not specified, so if a client were to attempt to validate
+            the RRs in the response, it might reject such a response,
since it would contain RRs, but probably a set of RRs
+           identical to what was sent in the SRP Update.</t>
        </section>

(The text indicating that the only possible error was ServFail was of
course incorrect. I think the text was originally intended to talk about
RCODEs other than those mentioned earlier, but the text was pretty
confusing when I read it, hence the update.)

On Mon, Oct 3, 2022 at 10:02 AM Esko Dijk <[e-mail]>
wrote:

> Yes, would agree to adding a sentence on that. Best places in the document
> for this are:
>
>
>
> 2.2.5.2 “Name Conflict Handling”  (close to the YXDomain response
> explanation) , or
>
> 2.3.5 “SRP Update response”    (covers SRP-specific aspects of the
> response, in general)
>
>
>
> Regards
>
> Esko
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Monday, September 26, 2022 16:59
> *To:* Esko Dijk <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [dnssd] SRP: name conflict while not knowing which name
> conflicts
>
>
>
> 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
>
>