How should an mDNS server handle a reverse-mDNS request?

Question

First, some background: avahid was causing me problems on my embedded Linux device (it had crashing bugs that didn't look like they would be fixed anytime soon) and I only needed minimal mDNS functionality (i.e. just enough so that someone on a Mac or PC could do a "ping6 mydevicename.local." and have that hostname resolve to my device), so I wrote my own minimalist mDNS server (in C) that basically just listens for multicast DNS packets and responds to them with the necessary mDNS records.

This mostly works -- in particular, doing the aforementioned ping6 test from a Mac resolves immediately and works just great.

I noticed, however, that if I do the ping6 from a Linux box, however, it only sort-of works. In particular:

• It takes the Linux client about 4 seconds to resolve the hostname
• This 4 second delay happens for every ping packet that is sent … i.e. instead of sending one ping per second, the ping6 program ends up sending one ping every 4 seconds. (It does get the expected pong though)
• This problem did not occur when I was running avahid on my embedded Linux device, so I think the behavior must be caused by something my new mDNS server is doing that isn't correct.
• When this occurs, my mDNS server gets reverse-mDNS packets from the client, like what is shown in this debug output:

[…]

RECEIVED 90 IPv6 BYTES FROM [fe80::21c:abff:fe00:a60] on s6#2 (sock=6)
--- Received IPv6 Data (90 bytes): -------------------------------------
0000: .............3.2 [00 00 00 00 00 01 00 00 00 00 00 00 01 33 01 32]
0016: .6.4.2.0.e.f.f.f [01 36 01 34 01 32 01 30 01 65 01 66 01 66 01 66]
0032: .b.2.0.6.2.0.0.0 [01 62 01 32 01 30 01 36 01 32 01 30 01 30 01 30]
0048: .0.0.0.0.0.0.0.0 [01 30 01 30 01 30 01 30 01 30 01 30 01 30 01 30]
0064: .0.0.0.8.e.f.ip6 [01 30 01 30 01 30 01 38 01 65 01 66 03 69 70 36]
0080: .arpa.....       [04 61 72 70 61 00 00 0c 00 01]
HandlemDNSRequest:  transID=0 flags=0 numQuestions=1 numAnswers=0 numAuthorityRRs=0 numAdditionalRRs=0
Ooh, a reverse-mDNS request for [3.2.6.4.2.0.e.f.f.f.b.2.0.6.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa] scope=3

So my questions are:

• What would cause the Linux mDNS hostname-resolution client software (NSS-resolver?) to have this four-second delay every time a program tries to resolve an mDNS hostname using my mDNS server?

• What is the appropriate way to respond to an mDNS request like the one above? I looked in the mDNS and DNS specs but couldn't find anything explicit about what is required. I tried having it respond with the usual information (hostname, IP addresses, etc), but that didn't make the delay go away.

• Is there anything else I might be doing wrong? (Other than attempting to roll my own mDNS server -- but believe me it's not something I'd do if I felt there was a better alternative; avahid just wasn't cutting the mustard)

Answer 1

I was finally able to figure out what was going wrong by using an nTap device and WireShark to capture the mDNS traffic being generated by the device both by Avahid and by my own program. Since avahid didn't generate this problem, presumably the responses generated by avahid were the ones Linux was looking for. I updated my program to generate similar responses and that made the 5-second delays go away.

In particular, the reverse-mDNS responses generated by avahid contained 0 queries and 1 answer (of type hostname) only, as shown in the attached wireshark screenshot.