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

[Lanlan Pan <[e-mail]>]

Ted Lemon <[e-mail]> 于2021年8月13日周五 下午7:19写道：

> 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.
>
+1,  advertise without asserting uniqueness.
To join in a Thread zone,  srp client should be authenticated through
J-PAKE or other protocols. the srp client only its own the srp server, the
srp server can only ensure the uniqueness in its zone, but not asserting
the uniqueness with other zones.
If srp client migrating to a mdns client, just follow the mdns conflicts
policy.

> > 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.
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>