Re: [dnssd] Adoption call for draft-sctl-advertising-proxy

[Ted Lemon <[e-mail]>]

On August 12, 2021 at 6:32:47 AM, Martin Turon (
mturon=[e-mail]) wrote:

Is the case of a device conflicting with itself handled? Specifically,
imagine a dual-radio device (WiFi and Thread) which for some reason
migrates from being an SRP client to an mDNS client or vice versa.  When
the device tries to re-register its services to direct to its new,
renumbered IP addresses, could its own stale records on the proxy possibly
lock it out?

This is exactly the discussion I think we want to have.

With a single SRP server, this is a non-problem: the SRP First-Come,
First-Served Naming mechanism guarantees that if the same client registers
twice, it will be recognized the second time and its update will supersede
the previous registration, rather than conflicting with it.

With multiple SRP servers, we have a problem because the SRP client might
register with a different SRP server the second time, since it has no idea
it's connected to the same infrastructure (and indeed the SRP server
contact mechanism may be different, so that which server is updated is
non-deterministic or just not under the client's control). In this case,
we'll see a conflict when the second update comes in.

The way I'm currently proposing to address this is by requiring SRP
replication when there is more than one SRP server, and by not renaming,
but rather waiting for the conflict to resolve. With SRP replication, we
can use FCFS naming to see that it's actually the same client doing the
update, so there's no conflict at the SRP level. The only conflict is in
mDNS. When the SRP update propagates to the SRP server with the conflicting
data, that SRP server will remove the old data and replace it with the new,
which eliminates the conflict.

I think this is pretty tight; the only problem is that it does rely on SRP
replication working well. If SRP replication gets wedged, then the conflict
won't be resolved until the old data expires. This is not great, of course.

An additional mitigation strategy is to not actually detect conflicts. If
we have two conflicting registrations, and SRP replication doesn't resolve
them, then they just coexist until one goes away. This should happen when
the old SRP lease expires. This means that the consumer of the data has to
be smart about it: if there are conflicting TXT records, it needs to have a
strategy for choosing which one to trust. If there are conflicting address
records, it needs to do happy eyeballs.

The only other alternative is to rename. I think this is too heavy of a
solution, but I'm open to debate. The problem is that if we rename, we now
have two advertisements for the same accessory, so we're pretty much in the
same place we'd be with the "don't detect conflicts" strategy, except that
we have a gratuitous extra name.

So consumers of the data now have to use some other identifier than the
name to uniquely identify the device, and if there are two advertisements
under two different names that present the same identifier, we now have to
have a browse going to detect that, whereas if we don't change the name,
dealing with an unresolved conflict is a lot simpler.

With that said, that's just my thinking on this, and I'd really like to get
more eyes on this problem.