On 11 Sep 2012, at 02:41, james woodyatt <j...@apple.com> wrote: > Really? How has the architecture team managed to overlook the obvious > problem that homenets with interior routing domains comprising multiple > networks cannot use either mDNS or LLMNR, which are confined to link-local > multicast scope, without requiring name service proxies? > > As Brian notes, you could try to resurrect SLP, but-- really? I don't see > that happening. Name service proxies also sound like a major undertaking > compared to ordinary unicast DNS. What an exciting distributed database > scheme with which consider securing its integrity... I can't wait.
I'm informed that mDNS proxying is already understood and present in several devices. > Alternatively, you could try to extend mDNS and/or LLMNR to support a wider > multicast scope, then require routed homenets to implement some kind of > multicast routing protocol. That sounds like a big specification effort and > I'm not sanguine about the chances for adoption there. Either of the two above is assumed, with the arch team tending towards proxying rather than extending multicast. The final recommendation would be part of a "solutions-draft", and not in the "architecture". > Finally, we could punt on the homenet routing problem, and just use > mDNS+DNS-SD exclusively-- I'm sure I can think of at least one major player > in the home networking space that would be quite happy to see such an outcome > turn out to be the status quo, but last I checked, this working group didn't > like that idea very much. > > So, um-- I guess the answer to the Arch Doc team's question should be, "NAME > ALL THE THINGS IN DNS!!" What am I missing? I shall attempt to clarify. Iff all "in-home" services can be reached (whilst in-home) by mDNS-like protocols then we do not need an "in-home" unicast DNS zone. To reach those same services from _outside_ the home does of course need them to exist in the global DNS, as pointed out by Curtis. To do that we need (I think) only two things: 1. the ability for the device (or the network on its behalf) to register a FQDN for that device. 2. the ability for clients of that device to learn that FQDN when it's bookmarked so that they can reach it from outside. In the absence of an internal Unicast DNS zone all of the discussion of what that zone should be is irrelevant. No need for "ULA prefix-based" LQDNs, for example. So the point of the original email was to test that first assumption - i.e. what services don't (or can't) work in-home without a local unicast DNS zone. Ray _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
