dig -p 5353 @126.96.36.199 did much the same thing.
However, I have a device where I can resolve its name using
avahi-resolve but not using
$ avahi-resolve --name ding-5cd80b3.local ding-5cd80b3.local 192.168.0.248 $ dig +short -p 5353 @188.8.131.52 ding-5cd80b3.local ;; Warning: ID mismatch: expected ID 60466, got 0
With neither can I do a reverse lookup:
$ avahi-resolve --address 192.168.0.248 Failed to resolve address '192.168.0.248': Timeout reached $ dig +short -p 5353 @184.108.40.206 -x 192.168.0.248 ;; connection timed out; no servers could be reached
The device that's advertising its name is a simple IoT device so I'm not surprised that it has very basic mDNS support (if uses the mDNS support provided by the ESP-IDF).
I've tried using verbose flags with both
dig to see if either would give me some insight into what's happening but in neither case did I get any extra insight.
I'm guessing that
ID mismatch means that
dig actually is getting a response but is refusing to show it as it's interpreting this as a case of DNS spoofing while
avahi-resolve is being more forgiving.
Is there any way to get
dig to be more forgiving (I tried
+besteffort) or any way I can see what's going on here, short of using Wireshark?
I'm working on Ubuntu and, as noted, the device in questions is using the ESP-IDF.