cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
287
Views
1
Helpful
2
Replies

DNS Pointer Record Not Always Created Using Meraki/IOS DHCP

mbrown-revitycu
Level 1
Level 1

We use a mix of Meraki L3 and Cisco ISRs in our environment to perform our routing and to also function as DHCP servers for our various locations.

We also have a MS Active Directory environment running on Windows domain controllers, which provide internal DNS services for the network. We also have Umbrella virtual appliances in the environment for DNS inspection and external resolution.

PCs in our network receive both their IP addresses and DNS server information from the requisite device (Meraki L3 or Cisco ISR) at their location. The DHCP assignment tells the PCs to use one of the Umbrella VAs as their primary DNS, and one of the other Umbrella VAs as the secondary.

The issue we have had forever that we can't figure out is why the PTR record for PCs is inconsistently created in the DNS table on the DCs. Sometimes the record is created, but sometimes it just isn't. 

This causes issues because of a service we utilize which checks *both* the forward and reverse lookups to verify whether a PC can access the service. If the PTR records is absent, the user is unable to access the service from that PC.

The fix is to manually access the forward lookup record for the PC, and force create the PTR record. This isn't a world ender, but it certainly is annoying.

Any suggestions on what we may be missing here?

Thanks!

2 Replies 2

access-list 100 permit udp <pc ip> any eq 53
access-list 100 permit udp any eq 53 <pc ip>

Debug ip packet 100

Check if PC ask correct dns server (umbrella) or not.

It can some dns spoofing attacks.

MHM

Check if PC 

pieterh
VIP
VIP

normally in a ADC integrated DNS it is the client that registers itself in DNS (forward and reverse).
this behavior can differ between client OS versions

you can enable the option to let the DHCP  server register the client in DNS for clients that do not support registring themselves
furthermore the ADC-DNS zone has a security option so that not everyone can update any record, but only "authorized" servers/clients -> so a client may not be able to overwrite another clients PTR record if the lifetime is still valid
as this registration is a one-time action this is not resolved when the lifetime has expired.

if inconsistency occur delete the record, and on the (MS-Windows) client issue "ipconfig/registerdns" or reboot the client