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

[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, September 23, 2022 17:14
To: Esko Dijk <[e-mail]<mailto:[e-mail]>>
Cc: Kangping Dong <[e-mail]<mailto:[e-mail]>>; Tim Wicinski <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, September 23, 2022 15:59
To: Tim Wicinski <[e-mail]<mailto:[e-mail]>>
Cc: Esko Dijk <[e-mail]<mailto:[e-mail]>>; Kangping Dong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, September 23, 2022 14:56
To: Esko Dijk <[e-mail]<mailto:[e-mail]>>
Cc: Kangping Dong <[e-mail]<mailto:[e-mail]>>; Tim Wicinski <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: Friday, September 23, 2022 12:28
To: Esko Dijk <[e-mail]<mailto:[e-mail]>>
Cc: Kangping Dong <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Ted Lemon <[e-mail]<mailto:[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