Dumping Avahi & Bonjour, DNS-SD Zone Files

I'm looking to make improvements to the Go library for mDNS: https://github.com/davecheney/mdns/

I've spoken with the author, who simply says "I got it to a point where it worked for me", and that's fine, well within the spirit of open source.

He mentioned some interoperability problems with Avahi, Bonjour and dns-sd discovery tools not finding the services he has exported.

I'm looking to understand what records are published by Avahi when doing a simple service with a port, and a simple name.

I had expected an appropriate version of:

dig @localhost .local -t AXFR

Might have Avahi export it's zone, but it didn't work for me (cue "you are doing it wrong"!) - I'd like to understand the minimum records exported by a typical Avahi service, and examine the same from the automatically exported Lee-Hambleys-Macbook.local from the Apple implementation on my notebook that I might be able to improve the Go lang support for mDNS.

When other people are working with Avahi/Bonjour/mDNS, what tools do they use to dig in and check that things are working as expected?

The kind folks of #avahi were kind enough to give me the following tip:

 killall -USR1 avahi-daemon

That causes avahi-daemon to dump it's zone file to the syslog.

But ideally I'd like to know how best to query the server, tcpdump also looks promising, but it's still only showing records that get lookedup, not a complete dump of everything that's in the zone:

sudo tcpdump dst port 53
Password:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:43:28.883763 IP 192.168.178.41.50916 > resolver2.opendns.com.domain: 50479+ A? e3191.c.akamaiedge.net. (40)
09:43:29.046201 IP 192.168.178.41.61989 > resolver2.opendns.com.domain: 55378+ PTR? 251.0.0.224.in-addr.arpa. (42)
09:43:29.123784 IP 192.168.178.41.56659 > resolver2.opendns.com.domain: 26471+ A? p05-btmmdns.icloud.com.akadns.net. (51)
09:43:29.819277 IP 192.168.178.41.53504 > resolver2.opendns.com.domain: 32010+ PTR? 220.220.67.208.in-addr.arpa. (45)
09:43:47.379251 IP 192.168.178.41.50916 > resolver2.opendns.com.domain: 50479+ A? e3191.c.akamaiedge.net. (40)
09:43:55.900406 IP 192.168.178.41.60511 > resolver2.opendns.com.domain: 32846+ AAAA? lc22.prod.livefyre.com. (40)
09:44:04.115159 IP 192.168.178.41.50916 > resolver2.opendns.com.domain: 50479+ A? e3191.c.akamaiedge.net. (40)
^C
7 packets captured
3187 packets received by filter
0 packets dropped by kernel

mDNS does simply not support zone transfers due the way the protocol works. As far as I can tell there are two possible approaches:

1) Try brute force approach, by querying the target (server/subnet). You can do this with dig, just send the query to multicast address and query for your target, eg.

> dig -x 192.168.0.10 -p 5353 @224.0.0.251

There are also a few ready scripts and tools that assist in enumerating mDNS targets. Some examples include

• MDNSRecon
• avahi-browse
• mdns-scan
• Bonjour Dumper
• dns-sd -Z and friends

2) Force the daemon to dump its zone file (or settings). You already found out that Avahi obeys

>killall -USR1 avahi-daemon

Apple's Bonjour includes mDNSResponder which does not implement dumping zone information. However you can add more logging for similar benefits

> A SIGUSR1 signal toggles additional logging, with Warning and Notice
> enabled by default:
>
> % sudo killall -USR1 mDNSResponder
>
> Once this logging is enabled, users can additionally use syslog(1) to
> change the log filter for the process. For example, to enable log
> levels Emergency - Debug:
>
> % sudo syslog -c mDNSResponder -d
>
> A SIGUSR2 signal toggles packet logging:
>
> % sudo killall -USR2 mDNSResponder
>
> A SIGINFO signal will dump a snapshot summary of the internal state
> to /var/log/system.log:
>
> % sudo killall -INFO mDNSResponder

Also, Wireshark might be used to debug protocol errors. This should be enough for solving interoperability errors.