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

[Jonathan Hui <[e-mail]>]

On Fri, Aug 13, 2021 at 1:07 PM Ted Lemon <[e-mail]> wrote:

> On August 13, 2021 at 1:49:37 PM, Jonathan Hui ([e-mail]) wrote:
>
> On Wi-Fi, the device needs to discover the SRP server. Why can't
> dnssd-zone-discover help with that? If there is a single SRP server in the
> network and it is servicing both Wi-Fi and Thread networks, we don't need
> to deal with conflicts. If there are multiple SRP servers, then I hope SRP
> replication will address the vast majority of cases.
>
> dnssd-zone-discover lets you discover DNSSD zones that you can browse. It
> doesn't tell you about the SRP server.
>
Ah, yes, I was confused. Thanks for clarifying.

> We need a different DNSSD advertisement for that. Not a big deal.
>
Yes, agreed.

> Yes. Well, FWIW, my current code does both SRP replication _and_ doesn't
> defend names, so we may be getting operational experience on both. :)
>
That's great to hear!

> Another thing to be aware of is that because of the way mDNS works, if you
> are using mDNS for discovery, a name conflict when names aren't being
> defended will sit around in the cache for a few minutes. If names are
> defended, this doesn't happen; one alternative is to just defend names and
> count on SRP to deal with conflicts, but the downside of this is that now
> there is a delay before the new information appears.
>
> This delay could potentially be minimized by retrying to register as soon
> as the SRP replication update has been acknowledged by all SRP replication
> peers—right now my code (when name defense is enabled) just waits two
> minutes before re-attempting, which is a lot longer than should be
> necessary.
>
Sounds like a good idea to explore. My initial concern is that waiting for
positive confirmation from all peers can lead to other failure modes
resulting from poor implementation or connectivity. At the same time, those
same assumptions are what would lead us back to needing other mitigations.

--
Jonathan Hui