Re: [homenet] Understanding DNS-SD hybrid proxying [was: Firewall hole punching]

[Juliusz Chroboczek <[e-mail]>]

> In dnssd we have the “stitching” topic on our plate, around operation of dns-sd
> in unmanaged multi-link networks.  So this is timely discussion.

Aha, excellent.

> We’re beginning work on a BCP for the use of the discovery/advertising proxy in
> enterprise/campus networks, where there is administrative configuration, and
> scalability is a concern. The stitching topic would likely form part of a
> corresponding BCP for unmanaged operation, as per a multi-link homenet.

I could be wrong, but I believe that stitching could be just as useful in
managed networks.  I'm not especially enthused by the solution suggested
in Section 5.1 of dnssd-hybrid-05 (making a single hybrid proxy ubiquitous
through link-layer magic).

> The proxies ask about (discover) services on the link(s) they serve on behalf
> of the (remote) querier. For general info on how dns-sd works, see
> https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-05, Section 5 in
> particular.

The draft suggests that the hybrid proxy does not speak mDNS, but that it
gets the information from an existing mDNS cache (last paragraph of 5.1).
It appears that Markus' OpenWRT implementation follows this model.  As
a general rule, I'm not overly keen on solutions that require dependencies
between daemons, but Markus and Steven have a good track record of beating
such constructs into compliance.

> For more info on that, see
> https://www.ietf.org/proceedings/97/slides/slides-97-dnssd-hybrid-proxy-00.pdf

Will do, thanks.

> The other thing to be aware of is that there is “long lived query” support for
> the proxies being defined via the DNS Push Notifications and DNS Session
> Signalling drafts (https://tools.ietf.org/html/draft-ietf-dnssd-push-09 and
> https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-01).

Oh my.  Is that meant to be optional?

Thanks for all the info,

-- Juliusz