What I'm concerned about is using one protocol for internal name resolution and another for external.
Bonjour, mDNS and multicast DNS are synonymous. mDNS is based on DNS-SD, which is a conventional use of *existing* DNS RR types for service discovery. mDNS uses DNS-like messages. I'm OK with calling it "DNS-like" but to say that it is unrelated to DNS or a closed standard is just confusing the issues IMO. The Hamming distance between mDNS and DNS is virtually nil compared to other alternatives mentioned so far for internal name resolution (SLP, LLMNR, etc.) What this means in practice is that any resolver that deals with mDNS can also resolve global DNS names. I think that DNS and DNS-like protocols should be where we focus our limited time and energy for homenet naming use cases until someone comes up with a scenario that, by rough consensus, shows DNS to be unsuitable for homenet naming. Now back to Ray's original question, I can see a use for unicast mDNS resolution in homenet insofar as a previously cached binding might be validated with a unicast message. If that binding proves to be invalid, then the client could initiate a new discovery (using scoped multicast or some as yet TBD proxying scheme.) -K- On Mon, Sep 10, 2012 at 11:48 AM, Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > Don, > > Yes, based on, and it will be good to see those RFCs out. > > What I'm basically worried about here is ending up with one > toolset for homenets and a different toolset for small enterprise > networks, which seem much more likely to go the DNS way than anything > else. In practice there's no hard and fast boundary between home and > small business. > > Brian > > > On 10/09/2012 15:17, Don Sturek wrote: >> Bonjour is based on mDNS >> (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/) and >> DNS-SD (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-dns-sd/), >> both currently in the RFC editors queue..... >> >> Don >> >> On 9/10/12 6:53 AM, "Brian E Carpenter" <brian.e.carpen...@gmail.com> >> wrote: >> >>> On 10/09/2012 14:09, Ray Bellis wrote: >>>> On 10 Sep 2012, at 13:58, Brian E Carpenter >>>> <brian.e.carpen...@gmail.com> wrote: >>>> >>>>> Using literal addresses is evil for many reasons - surely we don't >>>>> need to >>>>> discuss that ancient question again? >>>> I wasn't promoting it, just noting that this is the current position, >>>> with Bonjour et al becoming the "preferred" way. The latter is "a good >>>> thing". >>> afaik Bonjour is a proprietary protocol. How can that be a good thing? >>> >>>>> The right question is whether DNS is the appropriate solution for >>>>> converting >>>>> local devices names to addresses, or whether there is some other >>>>> naming service that >>>>> should be the standard. Since DNS is the IETF standard for converting >>>>> names >>>>> to addresses, there would need to be a pretty strong case for anything >>>>> else. >>>> The IETF has _other_ protocols for naming services (mDNS, LLMNR) that >>>> are designed for local networks, albeit with the "wrong" multicast scope >>>> as far as we're concerned. >>> And SLP, explicitly designed for locating services. >>> >>>> My question is therefore more about whether (internal) unicast DNS is >>>> actually required at all. >>> And I'm saying that's the wrong question. >>> >>> I think the right question is whether there is an *open* standard for >>> discovering >>> service addresses from service names that is more suitable than DNS. >>> >>> Brian >>> >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> >> > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
