In part 1, I wrote a simple Core console app that could log the multicast requests it received. Running the simple Bonjour Browser utility, I could see this being logged
The lines _services_dns-sd seems to indicate some sort of services request being made, which made sense, given that Bonjour’s purpose for existing is to advertise services on a network. A quick Google for _services_dns-sd lead me to this Apple article https://developer.apple.com/library/content/qa/qa1337/_index.html.
This confirmed my hunch.
Devices running mDNSResponder-58.6 (Mac OS X 10.3.4) or later will respond to the “Service Type Enumeration” meta-query described in Section 10 of the DNS-SD specification. Issuing a Multicast DNS PTR record query for the name “_services._dns-sd._udp.local.” will return a list of service types being advertised on the local network.
Aside from the full stops being displayed as question mark characters, this looked pretty sensible.
First order of business was to actually parse the byte[] into its parts and display them. Back to RFC 6762.
Section 18 talks about the message format, but deals a lot in bits, rather than bytes. To help me understand the values a bit better, I decided to write each request out as bits.
I got something like this (each byte in its own line)
00000000 00000000 00000000 00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00001001 01011111 01110011 01100101 01110010 01110110 01101001 01100011 01100101 01110011 00000111 01011111 01100100 01101110 01110011 00101101 01110011 01100100 00000100 01011111 01110101 01100100 01110000 00000101 01101100 01101111 01100011 01100001 01101100 00000000 00000000 00001100 00000000 00000001
I started by trying to compare each part to the corresponding bit outline in the RFC. Nothing matched, so I went back to Google and found this piece on Wikipedia (https://en.wikipedia.org/wiki/Multicast_DNS). A quick read and the first example looked like that I wanted.
00 00 Transaction ID
00 00 Flags
00 01 Number of questions
00 00 Number of answers
00 00 Number of authority resource records
00 00 Number of additional resource records
07 61 70 70 6c 65 74 76 “appletv”
05 6c 6f 63 61 6c “local”
00 Terminator
00 01 Type (A record)
00 01 Class
To confirm, I went back to my C# and modified it to show the data in a similar shape.
Working with the first 12 bytes, I saw this in the console’s output
00 00 00 00 00 01 00 00 00 00 00 00
This looked identical to the example in Wikipedia. I then went about look for the null terminator. After some tricking around I ended up with this
00 00 Transaction ID 00 00 Flags 00 01 Number of questions 00 00 Number of answers 00 00 Number of authority resource records 00 00 Number of additional resource records 09 5F 73 65 72 76 69 63 65 73 07 5F 64 6E 73 2D 73 64 04 5F 75 64 70 05 6C 6F 63 61 6C _services_dns-sd_udplocal 00 Terminator 00 0C Type 00 01 Class
This is a near perfect match to the Wikipedia entry. The primary difference is the “Type” value (and the actual request content (_services_dns instead of appletv.local)
Type value of 0x0C is obviously different, so I hit Google again and found this lovely Microsoft article. https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd197470(v=ws.10)
It explains the various parts of the request/response and the 0C type is a PTR request. This seems appropriate for DNS service discovery! Huzzah.
Next step is to now respond with some data, probably in the form of a TXT record.
Tomas McGuinness 