On Wed, Aug 1, 2012 at 3:17 PM, Evan Hunt <[email protected]> wrote: > > Do we want applications caching mDNS replies into configuration files? > > I think not, and I think the DNS people will shout loudly about that. > > Hm... I'm a DNS people, but I'm not sure I object to this. You'd want > some mechanism for clearing old records out after the devices had been > gone from the network for a long-enough time, but that's not intrinsically > hard. > > Printing is an example, but this could apply to other apps as well (it's just that there are already millions of deployed mDNS printers about). One thing to keep in mind is that it is easier to modify the end hosts (OS providers regularly push updates) and print servers than the printers themselves.
The idea assumes you need to be on-site to discover and add the printer in the first place (establishing some level of "trust" in the process). The mDNS draft enforces this by filtering out a) multicast discovery responses that don't have a link-local multicast destination address, or b) unicast responses that don't have the same source prefix as the querier. CUPS (and I presume other print systems) already cache a great deal of info about my printer and additionally caching a GUA if it was advertised does not seem a reach. Here's an example from my /etc/cups/printers.conf: <Printer Officejet_Pro_8500_A909g> UUID urn:uuid:dbb55a90-16ba-3534-5c4a-6da0e0d327a1 Info Officejet Pro 8500 A909g MakeModel HP Officejet Pro 8500 A909g Series DeviceURI dnssd://Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D._pdl-datastream._tcp.local./?bidi ... </Printer> Here you see the service instance name "Officejet Pro 8500 A909g" which appears in my print dialog, together with other unique info that prevents it from being confused with yours, if you had one and I was visiting. If, at service discovery time, my printer had advertised a GUA then I'm suggesting it could have been cached as well. In that case, the print system would formulate a *unicast* DNS query to that GUA for a AAAA RR named "Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D". If a response is returned, that strongly implies the printer is reachable and no resolution is necessary (this would also solve the problem I currently have with printing to other LAN segments). If that query *fails* then indicates I need to do a fresh resolution. Here's where Michael's idea to advertise a FQDN binding (which can also be cached) comes in. But first... ** TERMINOLOGY ALERT ** I suggest we reserve the term "FQDN" to refer to names that have been fully qualified in the global DNS namespace (as they all probably were when the term was first coined) and use something like "LQDN" to refer to names that are qualified in a locally-served (non-delegated) DNS zone. ...so by FQDN I mean that the original mDNS query return something like foo.local. CNAME foo.example.com. (Yes, I realize we may need to invent some new RR to express the LQDN-to-FQDN mapping). > I regularly print to both my work and home printer remotely (yes, over > > IPv6. The CUPS server speaks IPv6 even if my home printer speaks only > > USB). > > I'm of the opinion that "remote access from offsite" should be a service > you can configure your printer to provide, but which is not the default. > > I think this is part and parcel of advertising the GUA and/or LQDN-to-FQDN mapping, as above, or not, under control of the user. Alternately, this functionality could be deployed in a print server which just connects via USB to the printer. Such a server could be tightly coupled to the client functionality and provide mutual authentication, privacy, etc. Of course, you get all these things if you just tunnel back to your site in the first place ;-) > In my ideal world (please indulge me in a moment of handwaving), you plug > in your printer, and tell it what its name is (or let it pick its own > default such as "LaserPrinter-3"); it announces itself to the local network > as providing local printing, and its name is placed in the .sitelocal > domain. > > *If* you check the box for "let the outside world print to me" -- which you > and I might want to do but most people wouldn't -- then it announces itself > as providing both local and remote printing, and its name is placed in > .sitelocal and then mirrored into the globally addressable domain that > you'd previously configured for your network: by preference, that would be > your private domain name, but if you don't have one of those then it could > mirror into a namespace controlled by your ISP, Apple, DynDNS or whatever. > > If you were printing something, and you a found a printer via service > discovery which indicate that it could provide remote access, then you'd be > given the option to bookmark its global name and use it when you're away; > if it isn't configured for remote access then you woulnd't be given that > option. > > A similar mental model could apply to the "fridge" and "lamp" examples > we've been kicking around as well -- you won't normally *want* them to be > globally accessible, but if you do, you should tell them so and let them > work it out with your network. (This is the point I was trying to make at > the mic yesterday, but I'm not sure it came across.) > > Yep. I'm pretty sure this could be accomplished by some form of "gateway" (like the print server I described above). -K- > -- > Evan Hunt -- [email protected] > Internet Systems Consortium, Inc. >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
