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

[Ted Lemon <[e-mail]>]

On August 12, 2021 at 11:08:44 PM, Simon Lin (
simonlin=[e-mail]) wrote:

> 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.

Interesting—I'm realizing I completely misread Martin's question. I was
assuming that this client would continue to be an SRP client, not switch
between SRP and mDNS.

What's the solution to resolve the case where an SRP client migrates
to be an mDNS client. When the mDNS client tries to advertise its DNS
service, it will conflict with the SRP server of the original SRP
client. I don't think SRP replication can solve this problem.

As Jonathan said, always using SRP regardless of whether the device is
connected via Thread or WiFi can solve this problem. Also maybe the
device can unregister itself from SRP when it has migrated to WiFi,
which requires the device to remember the IP address of the SRP
server, or to use draft-tljd-dnssd-zone-discover.

I don't think dnssd-zone-discover helps with this. I think the client needs
to either unregister itself with SRP before migrating, or follow the same
protocol I mentioned earlier with respect to its service advertisement:
advertise without asserting uniqueness.

> 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.

Agree that SRP replication is the most user-friendly way of addressing
this problem.

> 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.

Does this strategy violate mDNS protocol? Moreover, if two different
devices register their service on different SRP servers using the same
name, it's not a good idea to not resolve the conflict since the
conflict will last for a long time.

No, it's allowed. If two devices claim the same name, we're now assuming
that this conflict will be resolved out of band rather than through mDNS
conflict detection. TBH, the only time I've ever actually seen an mDNS
conflict happen outside of deliberate testing was when a single device was
connected through two interfaces to the same link and didn't know it.

On the other hand we see conflicts all the time with SRP because of the
two-SRP-server mDNS conflict detection algorithm, so it's pretty clear that
SRP + mDNS conflict detection is a recipe for creating conflicts.

> The only other alternative is to rename. I think this is too heavy of a
> solution, but I'm open to debate.

It increases the complexity on every device that needs to browse for
mDNS services. I would prefer SRP replication to renaming.

This is a good point—SRP replication also increases complexity, but it
constrains it nicely to the more capable nodes on the network—the ones that
are acting as ad-hoc infrastructure and not as end nodes.