[mdnsext] Wide Area DNS-Based Service Discovery walkthrough

[Stuart Cheshire <[e-mail]>]

I previously submitted this draft:

<http://www.ietf.org/id/draft-cheshire-mdnsext-hybrid-01.txt>

Some people have asked me for a more detailed description of how clients perform the unicast queries. The Hybrid Proxy proposal talks about how information gets into the DNS namespace, but how does that data get back out again? I thought I'd illustrate that with a familiar example we've been using for many years here at IETF: Printing to the Terminal Room printer.

Here’s a detailed step-by-step walkthrough of how we find the IETF Terminal Room printer, starting with DHCP, and ending with a TCP connection sending the data to the printer. When you print from your Mac or iPhone, and give no second thought to how it magically knew about the IETF Terminal Room printer, this is what it's doing under the covers.

First, let’s see what my Mac learned from the local DHCP server:

> % scutil
> > list
>   ...
>   subKey [74] = State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP
>   ...
> 
> > show State:/Network/Service/21B5304C-C227-4932-BFCF-54B28F4CA1D2/DHCP
> <dictionary> {
>   Option_15 : <data> 0x6d656574696e672e696574662e6f7267
>   ...
> }

Option_15 is Domain Name. What domain name?

> % echo 6d656574696e672e696574662e6f7267 0A | xxd -r -p
> meeting.ietf.org

Great. Does meeting.ietf.org recommend we look in any Wide Area Service Discovery domains?

> % dig lb._dns-sd._udp.meeting.ietf.org. ptr
> 
> ; <<>> DiG 9.6-ESV-R4-P3 <<>> lb._dns-sd._udp.meeting.ietf.org. ptr
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35624
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4
> 
> ;; QUESTION SECTION:
> ;lb._dns-sd._udp.meeting.ietf.org. IN	PTR
> 
> ;; ANSWER SECTION:
> lb._dns-sd._udp.meeting.ietf.org. 3600 IN PTR	meeting.ietf.org.
> 
> ...
> 
> ;; Query time: 8 msec
> ;; SERVER: 130.129.5.6#53(130.129.5.6)
> ;; WHEN: Wed Mar 13 10:16:40 2013
> ;; MSG SIZE  rcvd: 188

Note, I can ask *any* DNS server this question and I will get the same answer. Let’s ask Google DNS instead:

> % dig @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr
> 
> ; <<>> DiG 9.6-ESV-R4-P3 <<>> @8.8.8.8 lb._dns-sd._udp.meeting.ietf.org. ptr
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24571
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;lb._dns-sd._udp.meeting.ietf.org. IN	PTR
> 
> ;; ANSWER SECTION:
> lb._dns-sd._udp.meeting.ietf.org. 1532 IN PTR	meeting.ietf.org.
> 
> ;; Query time: 21 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Wed Mar 13 10:18:27 2013
> ;; MSG SIZE  rcvd: 64

I still get the same answer. The DNS server I ask doesn’t have to be “on” my “local” network (whatever that means). I’m in Florida. Google DNS is I-don’t-know-where, 13 hops away, but it still gives the right answer.

> % traceroute -q 1 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
>  1  rtra (130.129.80.2)  1.369 ms
>  2  75-112-170-148.net.bhntampa.com (75.112.170.148)  14.494 ms
>  3  bun2.tamp20-car1.bhn.net (71.44.3.73)  19.558 ms
>  4  hun0-0-0-0-tamp20-cbr1.bhn.net (72.31.117.156)  20.730 ms
>  5  xe-8-2-0.bar1.tampa1.level3.net (4.53.172.9)  13.052 ms
>  6  ae-5-5.ebr1.miami1.level3.net (4.69.148.213)  27.413 ms
>  7  ae-1-51.edge1.miami2.level3.net (4.69.138.75)  15.552 ms
>  8  google-inc.edge1.miami2.level3.net (4.59.240.26)  48.852 ms
>  9  209.85.253.118 (209.85.253.118)  21.118 ms
> 10  216.239.48.192 (216.239.48.192)  21.890 ms
> 11  216.239.48.192 (216.239.48.192)  23.221 ms
> 12  *
> 13  google-public-dns-a.google.com (8.8.8.8)  32.961 ms

(For the rest of this example I'll use Google DNS for all the queries.)

In this case the PTR is self-referential — meeting.ietf.org is advising us to look in meeting.ietf.org, but it could easily be set up to direct us elsewhere.

But in this case it’s suggesting we look for services in meeting.ietf.org, so let’s do that:

A Mac with appropriate printer drivers installed will look for this service:

> % dig +short @8.8.8.8 _pdl-datastream._tcp.meeting.ietf.org. ptr
> term-printer._pdl-datastream._tcp.meeting.ietf.org.

There’s one printing service available here, called “term-printer”. That’s what you see when you press the “+” button in the Print & Fax Preference Pane on Mac OS X.

To actually use it, the client uses this:

> % dig +short @8.8.8.8 term-printer._pdl-datastream._tcp.meeting.ietf.org. srv
> 0 0 9100 term-printer.meeting.ietf.org.
> 
> % dig +short @8.8.8.8 term-printer.meeting.ietf.org. AAAA
> 2001:df8::48:200:74ff:fee0:6cf8

So, to use this printer, the Mac connects to [2001:df8::48:200:74ff:fee0:6cf8]:9100, and uses the installed printer driver, which speaks the appropriate vendor-specific printing protocol for that printer.

If you’re using an iPhone then you don’t have vendor-specific printer drivers installed; instead it uses this generic IPP-based printing service:

> % dig +short @8.8.8.8 _universal._sub._ipp._tcp.meeting.ietf.org. ptr
> term-printer._ipp._tcp.meeting.ietf.org.

There’s one IPP-based printing service available here, called “term-printer”. Same name as the pdl-datastream printing service, and same physical hardware, but different printing protocol.

To actually use it, the client uses this:

> % dig +short @8.8.8.8 term-printer._ipp._tcp.meeting.ietf.org. srv
> 0 0 631 term-printer.meeting.ietf.org.
> 
> % dig +short @8.8.8.8 term-printer.meeting.ietf.org. aaaa
> 2001:df8::48:200:74ff:fee0:6cf8

Note: Same address as before, but different port number.

To use this printer, the iPhone connects to [2001:df8::48:200:74ff:fee0:6cf8]:631, and uses IPP to print.

And that, ladies and gentlemen, is how automatic Wide Area DNS-Based Service Discovery works.

Here at IETF, the records are added to the DNS manually by our capable network volunteers. The idea of the Hybrid Proxy is to populate the DNS namespace automatically, making Wide Area DNS-Based Service Discovery available to a broader community of users.

Stuart Cheshire