DHCP Hostname Priority Over mDNS

[dizzysn]

Hey folks,

I work for a school district as the Network Admin. I'm in charge of 16 buildings and almost 10,000 devices/users.

Recently over the last year, for reasons unknown, Meraki has started to report mDNS names over DHCP host names.

Because I work for a school district, blocking kids from the protected Wi-Fi and steering them towards the BYOD Wi-Fi has been a never ending battle.

This slow change I've seen to where a majority of devices are reporting mDNS now is causing some massive problems. Every single Chromebook, Android phone, and Smartboards are reporting back as these names. A serious number of iPhones and iPads are doing it. We're now also having Windows devices doing it.

At this point, there's a 50/50 shot that I'm blocking something legitimate instead of a rogue device on the network. This is starting to cause a MASSIVE headache, and tons of problems all over the district. At one school I ended up inadvertently blocking the entire administration staff's district issued cellphones from the network. I've inadvertently blocked Smartboards in the middle of class, and teachers while they're in the middle of Zoom calls or teaching.

I'm completely stuck right now. I can't risk having personal, unauthorized devices connected to the network that prevents a security vulnerability, but I also can't keep blocking teachers and admins.

For reference, we are using MR52 access points, and MS225 switches, with CentOS Linux DHCP servers. On a call with Meraki they basically just said "Oh well that's just how it is, nothing we can do," which I find completely mind-blowing. Being that we're the literal poorest district in the state (we only got the Meraki equipment from a massive one-time grant from the State), we have no money to purchase any of the MX appliances.

Is there anything at all I can do? I can't manually rename 10,000+ devices in the dashboard. I wrote a group policy to disable mDNS broadcasts, but it doesn't help us at all with the Macs, Chromebooks, Smartboards, iPhones, iPads and Android devices. I did write a new group policy to disable mDNS, but for whatever reason the Windows devices are still reporting back that way. We do not have SCCM (can't afford the licensing) or other options that we can push out new passwords to the Protected network, we would have to manually do this on every device, which simply isn't feasible.

This is extremely frustrating, and I'm not sure of a good way to fix it. Anyone found a solution?

[PhilipDAth]

Yep - many people have complained about not being able to set the protocol order used for determining names.

I would be using WPA2-Enterprise mode with RADIUS.  You can even have a single SSID, and drop people into different VLANs based on which groups they are in.

Splash Access also has an excellent system for the education market that allows students to self on-board devices.

https://www.splashaccess.com/splashaccess-education-campus/ 

[raltschwager]

Totally agree with this.  I'm not sure how having the device named with an mdns string is more convenient then having the host name as the client name in Meraki.  I also haven't seen a post explaining why it's a benefit to admins to have the naming order this way or why it's a hard-engineering problem to change it.  I'd be happy to show any Meraki engineer how this slows down our use of their system and ruins the "at-a-glance" nature of the interface. 

[dizzysn]

It's even more frustrating because when I brought it up with my solutions rep, they came up with all these other options that didn't solve the issue, and didn't really have much to say when I said "watch this" and shared my screen, pulled up the one single off-domain site that we have which uses Ubiquiti hardware, and there wasn't a single mDNS name anywhere. I showed him how I can instantly see exactly what every single device is at a quick glance. The response was "Yeah... that definitely seems like it might be helpful."

I honestly can't believe that THE networking company doesn't have a solution in place for this.