Subject: [dnssd] Wide Area DNS-Based Service Discovery walkthrough

From: Stuart Cheshire <[email-masked]>
Date: Wed, 23 Jul 2014 12:39:04 -0700

In preparation for discussion tomorrow of <http://tools.ietf.org/html/draft-cheshire-dnssd-hybrid-01> I’m re-sending this walkthrough of how Wide Area DNS-Based Service Discovery works. Here at the IETF meeting we’re using manually-entered DNS records; the Hybrid Proxy would automate the importation of the necessary records into the unicast DNS namespace, to make this accessible to people who don’t have highly talented IETF volunteers running their network.

When you tap the AirPrint button on your iPad and give no second thought to how it magically knew about the IETF Terminal Room printer, this is what is going on behind the scenes, starting with DHCP, and ending with a TCP connection sending the data to the printer. Since most people don’t have a shell login on their iPad, I’m going to illustrate this using examples on Mac OS X, which works the same way.

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

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.

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 Toronto. Google DNS is I-don’t-know-where, 11 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 (31.133.160.2)  1.032 ms
>  2  207.219.102.241 (207.219.102.241)  4.453 ms
>  3  nycmny83ci01.bb.telus.com (75.154.223.250)  20.588 ms
>  4  72.14.194.122 (72.14.194.122)  20.018 ms
>  5  209.85.248.180 (209.85.248.180)  11.793 ms
>  6  72.14.236.208 (72.14.236.208)  11.868 ms
>  7  72.14.239.93 (72.14.239.93)  20.319 ms
>  8  66.249.95.231 (66.249.95.231)  29.761 ms
>  9  209.85.250.223 (209.85.250.223)  24.389 ms
> 10  *
> 11  google-public-dns-a.google.com (8.8.8.8)  35.995 ms

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

The PTR is suggesting we look for services in meeting.ietf.org, so let’s do that:

A Mac 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:67c:370:128:a65d:36ff:fe32:44ba

So, to use this printer, the Mac connects to [2001:67c:370:128:a65d:36ff:fe32:44ba]: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 a different printing protocol, listening on a different port.

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:67c:370:128:a65d:36ff:fe32:44ba

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

To use this printer, the iPhone connects to [2001:67c:370:128:a65d:36ff:fe32:44ba]: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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Jul 2014 15:58:27 -0400

On Wed, Jul 23, 2014 at 12:39:04PM -0700, Stuart Cheshire wrote:
> 
> Note, I can ask any DNS server this question and I will get the same answer. 

<picky-pants>
s/any DNS server this/any DNS server that supports recursion this/
</picky-pants>

Stuart knows this, of course.  My point is that if you have a recursor
and the relevant data is in the public DNS, then you get it just like
any other DNS record.  Nothing is magic or special about the way this
all works.  It's bog standard DNS when it uses DNS.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]