Avahi & Bonjour dumping, DNS-SD zone files

Question

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

I spoke with an author who simply says: “I got to the point that it worked for me,” and it’s fine, good in the spirit of open source.

He mentioned some compatibility issues with the Avahi, Bonjour, and dns-sd detection tools, not finding the services he exported.

I want to understand what records Avahi publishes when performing a simple service with a port and a simple name.

I was expecting the appropriate version:

dig @localhost .local -t AXFR 

Avahi may be exporting it to the zone, but it didn’t work for me (cue “you are doing it wrong”!). I would like to understand the minimum records exported by a typical Avahi service, and learn the same from the automatically exported Lee-Hambleys-Macbook.local from the Apple implementation on my laptop that I could improve Go lang support for mDNS.

When other people work with Avahi / Bonjour / mDNS, what tools do they use to find and verify that everything is working as expected?

The kind #avahi people were kind enough to give me the following advice:

  killall -USR1 avahi-daemon 

This causes avahi-daemon dump the zone file in syslog .

But ideally, I would like to know what is the best way to request a server, tcpdump also looks promising, but it still shows only the records that are looking for, and not a complete dump of everything 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 

Answer 1

mDNS simply does not support zone transfers because of how 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 a request to the multicast address and a request for your purpose, for example.

dig -x 192.168.0.10 -p 5353 @ 224.0.0.251

There are also several predefined scripts and tools that help list mDNS targets. Some examples include

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

2) Make the daemon reset the zone file (or settings). You already learned that Avahi obeys

killall -USR1 avahi-daemon

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

Signal SIGUSR1 switches the additional registration, with warning and notification by default:

  % sudo killall -USR1 mDNSResponder 

Once this logging is enabled, users can optionally use syslog (1) to modify the log filter for the process. For example, to enable the Emergency - Debug levels log:

  % sudo syslog -c mDNSResponder -d 

The SIGUSR2 signal switches packet logging:

  % sudo killall -USR2 mDNSResponder 

The SIGINFO signal resets the snapshot summary of the internal state in /var/log/system.log:

  % sudo killall -INFO mDNSResponder 

In addition, Wireshark can be used to debug protocol errors. This should be enough to solve compatibility errors.