Hi, I too have the problem with mdnsd and the flat battery - on a Samsung Note 2 on Android KitKat 4.4.2 which has been going flat several times a day. Just thought I would offer some thoughts from my investigation. Sorry for the very very long and probably rambling technical post.
mdnsd (aka Bonjour on Apple, Zeroconf etc) has two bugs that Google fixed between Android 4 and Android 5 (according to Android Open Software Project).
The main bug was titled 'Fix mDNS socket leak during network configuration changes' and this was fixed in March 2014 by a clever person at Google, however the fix doesn't appear until devices with Android 5 Lollipop. This bug could 'eventually lead to failure of the mDNS daemon when its file-descriptor table fills up with orphans.' - which is exactly what appears to be happening on my phone as the number of network sockets attached to the mdnsd service builds to about 580 (on my phone it adds about 28 orphans with each network config change - and network config changes reliably include anything WiFi, Mobile Data and Charging state). Soon after reaching the magic 580, the mdnsd service goes into a high CPU utilisation (100% of one CPU core), presumably as it fails to acquire additional sockets. As it does this, the power management decides the phone is really busy, increasing the speed of, and power to, the CPU cores, the battery consumption goes way up and the back of the phone gets hot. The only fix is a reboot.
However this is not the only problem - after all, the bug has been there since Android 4.4.2 was released, so something changed in November/December that is triggering the bug a in a big way. So what was that? Given that any application that wants to use mdnsd is required to install with CHANGE_WIFI_MULTICAST_STATE permission, a look with Permission Explorer (from Play Store) shows a limited set of applications that have that permission on my phone. They these basically fall into 4 groups - Nearby Devices/WiFi Direct, a bunch of Printing services, some Samsung stuff and Google Play services (which includes all the google services like backup, the sync services, gmail, maps etc etc etc and which is totally different to Google Play Store). (and a couple that I uninstalled while testing).
A look at the network traffic to see what is being queried with using this multicast DNS shows a separate query for general _Android_ devices (probably from Nearby Devices and/or WiFi Direct bypassing mdnsd), plus one regular consolidated query (which is what mdnsd is designed for) looking for things like printing (_IPP_), file sharing (_SMB_, _FTP_ etc) and a range of other standard sharing type services which could come from any of these apps that have the right permission. Given Nearby Devices and WiFi Direct are part of the Android 4.4.2 build, and my printing services haven't been updated, this leaves the Samsung stuff and Google Play Services. As people are reporting the same issues on non-Samsung devices - to me this (probably) points to something in the vast array of stuff lumped under Google Play Services. Google released V10 (up from V9) of play services in late October 2016 which would have rolled out probably in November or early December.
For me there are a number of possible 'official' remedies ... update to Android 5 or above - which I can't on my Note 2, but others may be able to (Check you don't have automatic update disabled on your phone); persuade Google to investigate whether something they did in Play Services V10 is triggering this 'old' bug on this 'old' version of Android and then fix Play Services - or buy a new handset. None of these seem particularly likely outcomes.
So I have been looking at alternative strategies. At the moment, I have rooted the phone and am running a script that restarts the mdnsd service every 30 minutes (#setprop ctl.restart mdnsd). This clears out the orphan network sockets caused by the bug which will hopefully stop the mdnsd service from getting into trouble and flattening the battery. Given how mdnsd works, this shouldn't cause application problems as long as it doesn't get restarted too often. If the script proves to work for a few days, I will investigate how to automatically start the script on boot from within android (you can't restart mdnsd from within a normal app). If regularly restarting the service doesn't work, and it turns out the orphan sockets are just becoming invisible, I will investigate whether replacing the mdnsd executable with one from a similar Android 5 phone fixes the problem, or whether I can use Android Open Source to re-build the executable after applying the patch changes.
I will report next if/when I get to a final solution - but I fear the solution won't sound like good news if you are not very technically minded - unless you finally want to justify a new phone.