LEAmDNS - Multicast DNS Responder

[LaborEtArs]

A (currently experimental) mDNS responder to (maybe) replace the current ESP8266 mDNS responder in the future.

Supported mDNS features (in some cases somewhat limited):

• Presenting a DNS-SD service to interested observers, eg. a http server by presenting _http._tcp service
• Support for multi-level compressed names in input; in output only a very simple one-leven full-name compression is implemented
• Probing host and service domains for uniqueness in the local network
• Tiebreaking while probing is supportet in a very minimalistic way (the 'higher' IP address wins the tiebreak)
• Announcing available services after successful probing
• Using fixed service TXT items or
• Using dynamic service TXT items for presented services (via callback)
• Remove services (and un-announcing them to the observers by sending goodbye-messages)
• Static queries for DNS-SD services (creating a fixed answer set after a certain timeout period)
• Dynamic queries for DNS-SD services with cached and updated answers and user notifications

In most cases, this implementation should work as a 'drop-in' replacement for the original ESP8266 mDNS code. Adjustments to the existing code should only be needed, if some of the new features should be used. See the LEAmDNS/mDNS_Clock and LEAmDNS/mDNS_ServiceMonitor examples for more information.

[earlephilhower]

@LaborEtArs thanks for the work on this! Seems like you closed 5% of our open bugs with this rewrite!

[acoulson2000]

I second the thanks! Looking forward to trying this out.

[TD-er]

Any estimate on when it may be considered no longer "currently experimental" ?
It now has the "2.5.0" label on it, but what is the estimate of that release?

[devyte]

It is experimental because it is new, and some further minor work is still needed. It is also already the default given the long list of issues of the legacy implementation, and due to much better behavior and code quality.
The legacy implementation is still available, in case it's still needed, it just requires different usage.

[TD-er]

Sounds reasonable :)
And what estimated time frame is there for the 2.5.0 release?

[liebman]

I think Legacy is the default: https://github.com/esp8266/Arduino/pull/5442/files#diff-15e94833dc0151fd6f39ef509d8c1a9fR48

[devyte]

@TD-er per current schedule, the time frame for 2.5.0 is -4 days, as in we're 4 days overdue.
We're very close, but there's still a bit to do. The plan is to get something out the door over the next very few days.

[TD-er]

That would be sooner than I expected, so within a week is no problem (to me)

[LaborEtArs]

Hi! Have you got an iPhone nearby? If yes, just get a copy of ‚Discovery‘ from the App Store. With this app you can see all the mDNS services in your network without any Windows hassles. And please make sure, that you’ve got a call to MDNS.update() in you loop. Best regards Hartmut Albers (LaborEtArs) Am 16.12.2018 um 23:38 schrieb Guillaume <notifications@github.com>: Hello, I can't get mdns to work at all. It worked last time I tried, it was like a year ago. I have Windows 10 up to date, I have reinstalled Bonjour, and tried with the library examples, no luck, I can't ping or access esp8266.local. Is it just me? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[aboulfad]

Hello,
I am trying to figure out a way to use LEAmDNS to query hosts and return their IP, sort of what mDNSResolver does. (sadly using the latter with LEAmDNS somehow makes LEAmDNS not work)

Probing an existing host even if the answer shows a conflict, does return bunch of info including the IP in [MDNSResponder] _readRRAnswer, would that be a path to explore ? thanks.

[LaborEtArs]

Hi @aboulfad !
Have you tried the 'mDNS_ServiceMonitor' example? Adjust it to your needs first (type of service).
Which 'discoverer' do you use? Do you see your searched device there?

[aboulfad]

Hi @aboulfad !
Have you tried the 'mDNS_ServiceMonitor' example? Adjust it to your needs first (type of service).
Which 'discoverer' do you use? Do you see your searched device there?

Thank you for the reply. Indeed I looked at all examples and learned (i think) that there is no direct function/class/method to resolve .local hostnames to their IP (mDNS/zeroconf). I am sure this implementation does this already but maybe does not expose that method (e.g. MDNSResponder::queryHost ?)

I got inspired by the examples that one could potentially write a query local hostname method by using the .setHostProbeResultCallback and specify the host that needs to be resolved and extract the IP address from the answer. Sure there is an easier way that the author can whip up in a jiffy! I'll continue reading the code (afraid I know zeroC++)

I use dns-sd CLI and Discovery GUI on MacOS and the .local hostname I want resolved does not advertise any services (tcp,...), so it wont show by default, but doing the following does: (-q sends a MDNS query QU question)

$ dns-sd -q rpi3.local
DATE: ---Sat 30 Mar 2019---
 7:38:44.525  ...STARTING...
Timestamp     A/R Flags if Name                          Type  Class   Rdata
 7:38:44.969  Add     2  6 rpi3.local.                   Addr   IN     10.11.12.13

[LaborEtArs]

In fact, currently there is no method to resolve a hostname. mDNS is used to discover services, like a printer, ... To do so, a service query is done. The result of such a query would be zero or more service answers. Each answer then contains the name of the host, that offers the service (and IP address and port). Using these information, some can connect to one or more of these services.
The 'hostProbeResultCallback' is used for something completely different. It is used, to ensure, that the hostname of the device that executes the mDNS responder, is unique in the network. This again is needed to ensure, that services, the host offers can be resolved. This process is called 'probing' in the mDNS spec.
The usual network classes for the ESP are able to resolve a symbolic hostname (eg. rpi3.local) without any need for the sketch to do it. However, if a hostname needs to be resolved to an IP address DNS (without the m) would be the protocol to use.

[aboulfad]

The usual network classes for the ESP are able to resolve a symbolic hostname (eg. rpi3.local) without any need for the sketch to do it. However, if a hostname needs to be resolved to an IP address DNS (without the m) would be the protocol to use.

Interesting! I did not think the network classes in ESP can resolve local hostnames (ESP8266WiFiGenericClass::hostByName), so I tried it with the Pubsubclient .setserver(rpi3.local) and it worked :-) I also just checked w wireshark, indeed it uses mDNS QU query for that task. (quickly browsing and searching the code shows the usage of lwip mdns.h)

mDNS is also used to discover/query hostnames and inherently resolve that to an IP addr if there are no local "nameservers" (and not just for the purpose of service discovery). That is one of the requirements of zeronconf. The m for multicast is key to that capability in local network that does not have a namesever. When a client wants to reach another using the .local domain, it sends a multicast to (224.0.0.251) QU question. (sure you know all that)

I appreciate your answer, and thank you very much for simplifying my task, now don't need to learn or write any mDNS query method ;-) it's there !