DNS with Meraki DHCP

Court
Getting noticed

DNS with Meraki DHCP

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?

15 Replies 15
alemabrahao
Kind of a big deal
Kind of a big deal

It's probably a device issue, not a Meraki issue. Can you show an example?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
PhilipDAth
Kind of a big deal
Kind of a big deal

>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.

Court
Getting noticed

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.

alemabrahao
Kind of a big deal
Kind of a big deal

What you're saying doesn't make any sense. Have you tried running the commands below?

 

ipconfig /flushdns

ipconfig /release

ipconfig /renew

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Court
Getting noticed

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.

alemabrahao
Kind of a big deal
Kind of a big deal

How is the client IP assignment in the SSID configured?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Court
Getting noticed

Tunneled, layer 3 to the MX as the concentrator, VLAN tagged. I've also tried Bridged, L3 roaming, VLAN tagged with same results.

alemabrahao
Kind of a big deal
Kind of a big deal

in this case, I'm assuming that the APs and the MX are not on the same physical network correct?
 
Or is there any other reason, in particular, to use it in tunneled mode?
 
If you configure it in Bridge Mode, is the result the same?
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Court
Getting noticed

They are on the same network. I originally used bridged, L3 roaming, VLAN tagged with same result, so was trying tunneled too.

alemabrahao
Kind of a big deal
Kind of a big deal

No no, I'm talking about Bridge Mode without enabling L3 roaming.

 

alemabrahao_0-1682354773074.png

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Court
Getting noticed

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.

Court
Getting noticed

So my next question is, am I missing something on Umbrella config here, or is this a bug in Meraki?

MichelSchuurman
Conversationalist

Hi Court, 

We're running into the same issue. Umbrella integration in place, DHCP on the MX and DNS on our ADDS. 

Cannot get PRT working. 

 

Dit you get this working? Some more you found out?

 

Court
Getting noticed

We could never get it to work, so we left DNS and DHCP roles on our DC.

Meraki handles DHCP on our Meraki network management subnets though.

Jschiller412
Comes here often

We are encountering similar issues in our environment. DHCP is dished out via the Meraki MX firewalls. However, we noticed that Reverse DNS Lookups are not being auto-populated. In addition, we are integrated with Cisco Umbrella. 

 

We are looking to have Reverse Lookup Zones auto populated from forward lookup zones. Forward lookup zones are working fine.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels