0

I thought avahi-resolve and dig -p 5353 @224.0.0.251 did much the same thing.

However, I have a device where I can resolve its name using avahi-resolve but not using dig:

$ avahi-resolve --name ding-5cd80b3.local
ding-5cd80b3.local  192.168.0.248

$ dig +short -p 5353 @224.0.0.251 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 @224.0.0.251 -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 avahi-resolve and 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.

George Hawkins
  • 111
  • 3

1 Answers1

1

The problem does indeed seem to be with the underlying ESP-IDF library and its mDNS support.

It does not include the ID included in the original query in its response, it always just uses 0. Hence the dig error saying ID mismatch: expected ID 60466, got 0.

I've logged issue #5574 against the ESP-IDF to address this.

George Hawkins
  • 111
  • 3