mdnsd is case-sensitive when RFC 6762 says mDNS should be case insensitive.

[abrender]

I installed OpenWRT on a new device and it was given the default hostname 'OpenWrt'. The umdns service responds to mDNS requests for OpenWrt.local by returning the device's IPs. However, contrary to RFC6762, the umdns instance does not respond to mDNS requests for case-insensitive equivalents such as: openwrt.local.

The case sensitivity of mdnsd causes the following confusion:

After the install (or a reboot of the OpenWrt device) I am able to SSH into the device using the command ssh openwrt.local . After some time the hostname openwrt.local stops working (however ssh OpenWrt.local does work work (cAsE sEnSiTiVe)).

This happens because mdnsd announces it's OpenWrt.local hostname (code) and mDNS clients (Avahi in my case because I'm using Ubuntu) cache that information and respond to local mDNS requests in a case-insensitive manner per RFC6762. openwrt.local works after mdnsd makes the announcement, and before the client's mDNS cache is flushed. Restarting the umdns service causes a new announcement to be made, avahi caches the info and the all-lowercase hostname (openwrt.local) begins to work again.

From the RFC:

The simple rules for case-insensitivity in Unicast DNS [RFC1034]
[RFC1035] also apply in Multicast DNS; that is to say, in name
comparisons, the lowercase letters "a" to "z" (0x61 to 0x7A) match
their uppercase equivalents "A" to "Z" (0x41 to 0x5A). Hence, if a
querier issues a query for an address record with the name
"myprinter.local.", then a responder having an address record with
the name "MyPrinter.local." should issue a response. No other
automatic equivalences should be assumed.

It seems like a good first step here would be to change some of the string comparisons in dns.c to be case insensitive. Separately the code in cache.c may also be updated to support case-insensitive querying of mdnsd's local cache.

I appreciate that OpenWrt & mdnsd are open source projects, the developers work for nothing in return and there is no requirement for action on their parts. I am filing this bug for informational purposes, to help others understand problems they may experience and as a way for me to track potential pull requests to address this issue.