2

I am looking for a way to make reverse mDNS query on OSX over IPv6 only. I am not interested by solution using IPv4.

The following works on Linux with dig 9.16.1:

dig +short @ff02::fb -p 5353 -x 2001:db8::1

I've installed dig 9.16.7 with homebrew on OSX, that command with the exact same arguments produces a timeout. And there is no sign of the outgoing query on Wireshark.

The following works well on both Linux and OSX:

dig +short @224.0.0.251 -p 5353 -x 192.168.1.23

The binary avahi-resolve-address is not available on OSX and I didn't find a way to make a reverse DNS works with dns-sd.

Here is the operating system version used:

  • OSX version: Catalina 10.15.7
  • Linux: Ubuntu 20.04
djoproject
  • 147
  • 2
  • 7

1 Answers1

2

I found a couple of ways to do this, but they're both a bit ugly. First, you can use dns-sd -q and specify the ptr record type... but you need to convert the address you want to look up into nibble-by-nibble reverse format by yourself. For example, to look up fe80::4e6:97e7:d892:d977 you'd use:

dns-sd -q 7.7.9.d.2.9.8.d.7.e.7.9.6.e.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa ptr

Unfortunately, this only seems to work for link-local addresses, not public addresses. I have no idea why. Also, note that dns-sd doesn't exit automatically after doing the lookup, but keeps monitoring for changes. You need to kill it after a bit.

You can also use dig, somewhat like your original command, but you need to tell it which interface to send the query out over, and in a rather weird format. The "standard" thing to do would be to add a zone index for the interface, e.g. to send it to ff02::fb over en1 you'd use @ff02::fb%en1. But dig doesn't like that format, so you have to be sneakier. BSD-based unixes, including macOS, allow you to put a numeric zone index in the second 16-bit word of some kinds of addresses, and that does work here. Here's a (anonymized) example where I use netstat -rn -f inet6 to find out that 2001:db8:1234:5678::/64 is on interface en1, that interface's link number is 5, and then use that to do a lookup (I added ^^^s to emphasize the relevant parts):

% netstat -rn -f inet6
Routing tables

Internet6:
Destination                             Gateway                         Flags         Netif Expire
[...]
2001:db8:1234:5678::/64                 link#5                          UC              en1       
                                        ^^^^^^                                          ^^^
[...]
% dig +short @ff02:5::fb -p 5353 -x 2001:db8:1234:5678:109f:8688:b2d1:3f12
                   ^
Gordons-MacBook.local.
Gordon Davisson
  • 11,036
  • 3
  • 27
  • 33
  • Thanks for your answer. It is indeed a little bit ugly but it works! About your solution with `dns-sq` , as you told, requests are going out for link-local address but not for global unicast address, I can see it with Wireshark. Sadly the hosts I am targeting only answer to mDNS with their global unicast addresses. (Ubuntu hosts with Avahi) About your solution with `dig` and putting the zone id into the second 16-bit word, it produces what I needed. But I'll be interested if you have any documentation about it, it is the first time I see the zone id being put inside the IPv6 address. – djoproject Oct 13 '20 at 07:52
  • @djoproject I don't know of any good documentation on embedding the zone ID in the address. I think I originally discovered it because some macOS tool was reporting a link-local address with a nonzero second group, e.g. fe80:5::something, and I eventually figured out that the zone ID was getting converted to that format somewhere inside the network stack. The [wikipedia article I linked](https://en.wikipedia.org/wiki/IPv6_address#zone_index) mentions it, but only in passing and it doesn't cite a reference. – Gordon Davisson Oct 13 '20 at 14:22
  • @GordonDavisson, IPv6 Zone IDs are required when using link-local addresses because every link-local network is the same network, and a host may have multiple interfaces on different physical networks, but the link-local network is the same for all of them. At this time, Zone IDs are only allowed on link-local addresses due to security concerns (RFC 6874): "_To limit this risk, implementations MUST NOT allow use of this format except for well-defined usages, such as sending to link-local addresses under prefix fe80::/10. At the time of writing, this is the only well-defined usage known._" – Ron Maupin Oct 13 '20 at 15:17
  • @RonMaupin Since multicast addresses starting with ff02:: are also link-local, wouldn't it be normal/ok to use (or require, as macOS seems to) a zone ID with them? – Gordon Davisson Oct 13 '20 at 21:00
  • But the RFC says sending to link-local addresses under the `fe80::/10` prefix is the only usage at this time. There is no mention in any RFC about using the Zone ID with any multicast addresses. – Ron Maupin Oct 13 '20 at 21:14