Testing a new subnet using Meraki for DHCP and existing Windows DNS server. Both wired and wireless clients connect fine to the new subnet, can communicate with the DNS server, resolve names, but clients on the new subnet cannot update their DNS record on the server. Wired clients will update if you manually delete the existing DNS entry. Wireless clients will not update at all, they get a dynamic update refusal code 5. I know Meraki DHCP doesn't support updating reverse lookup records, but why would I be having trouble with client updates to DNS host records?
It's probably a device issue, not a Meraki issue. Can you show an example?
>they get a dynamic update refusal code 5.
This happens when the machine account requesting the reverse DDNS update does not have permission to do the update. A common cause is a machine does DHCP, gets an IP address, and then adds it via DDNS. At this point, that machine owns the record (Windows permission wise).
Sometime later a different device gets that same IP address via DHCP. It goes to update the existing reverse record - but it does not own it - the prior device does, and Windows DNS refuses the update.
A bit of a fundamental problem with Windows DDNS huh? It expects that once a device gets an IP address it will never change.
I often solve it by changing the default permission on the reverse DDNS zone to allow unauthenticated updates. This means anything can update a reverse DNS entry. If you do a "nslookup" you have to consider that the returned entry is not guaranteed to be who it says - but reverse DNS is mostly for information purposes anyway.
So the clients I'm testing previously used DHCP and DNS from the same Windows Server, and DHCP created their DNS records. Moved the same clients to the new subnet using Meraki DHCP, same DNS server, and I've manually removed their previous DNS records from the server. Wired clients will register a new DNS entry, but wireless clients on the same subnet will not register a new DNS entry. What would cause only the wireless clients to not be able to register? If I plug the wireless laptop into a network port configured with the newly configure subnet, it will register.
What you're saying doesn't make any sense. Have you tried running the commands below?
ipconfig /flushdns
ipconfig /release
ipconfig /renew
Yes, of course I've tried that. I know it doesn't make sense, yet its happening. Both wired and wireless clients are able to contact the DNS server and resolve names from it.
How is the client IP assignment in the SSID configured?
Tunneled, layer 3 to the MX as the concentrator, VLAN tagged. I've also tried Bridged, L3 roaming, VLAN tagged with same results.
They are on the same network. I originally used bridged, L3 roaming, VLAN tagged with same result, so was trying tunneled too.
No no, I'm talking about Bridge Mode without enabling L3 roaming.
Ok I think we've narrowed down the problem. When using Umbrella integration on an SSID that uses Meraki DHCP, DNS registrations are not processed, and the local domain name is in the exclusions list. Name resolution does work though. If the SSID with Umbrella is using DHCP on the server, DNS registrations work.
So my next question is, am I missing something on Umbrella config here, or is this a bug in Meraki?