DHCPRELEASE and DDNS to AD DNS

[#1]

We have VPN appliances that are acting as DHCP Proxies for clients to our Infoblox DHCP servers. The VPN appliances both request and release leases when a client connects and disconnects from the VPN service.

We are trying to sort some issues with DNS updates and the DNS records in AD DNS with the clients. One issue that I am trying to look further into is if the Infoblox DHCP server sends a DDNS update to delete the DNS records associated with the client when a DHCPRELEASE is issued by the VPN appliance.

From all the logs I've reviewed to date, it doesn't appear that the server sends the request to AD DNS to update/remove the records. I have also been unable to find any documentation regarding how Infoblox DHCP/DDNS handles this or if there are configurable options. My understanding from various searches is that ISC-based DHCP is supposed to send this request as part of the DDNS service.

I figured I would ask here prior to opening a support case.

Cheers.

[#2]

If the IB DHCP boxes are sending the DDNS updates on lease issue then when the lease is released they should send the approprate update/delete.

Couple of counter questions;

1) Are the DHCP servers setup to use GSS TSIG to authenticate to the windows DNS servers?

2) Have you done any packet captures to ensure that your VPN appliances are in fact sending the DHCP RELEASES?

If 1) No and 2) Yea, then you are most probably runinng into a permission denied error on the DDNS Delete.  I know it sound strange that the permissions on the MS DNS server will let an unautheenticated update happen but will prevent the deletes.  However it happens all the time.  

Once you start having to deal with security ACLS on MS DNS, it is just way easier in the long run to setup Gss Tsig, resecure the DNS server than be constantly tweaking the ACLS.  Remember if this is the case then you could actualy have a pretty big DNS security problem.  Because if the IB DHCP server can send unauthenticated updates... then any client windows/linux/whatever can too.  They might not stick to updating their own DNS records.  Just imagine if a rouge client came on your network and updated all the DC _msdc service records durring the middle of the day.  

[#3]

To answer your two questions:

1) Yes, we are using GSS-TSIG for our updates.

2) I have not done packet captures, but the DHCPRELEASE packets being logged by the DHCP server's SYSLOG indicate that they are being received.

That's why I was specifically asking, as there is nothing to indicate that post-release updates are being sent.

[#4]

Try hunting down your dns.log file, I think it's usually in the windir\System32\Dns folder. It should list the dynamic updates that are being received. I had a problem a while back where the DNS server wouldn't process an update because it needed both forward and reverse zones to be present, it wouldn't work if one of the zones was missing, unfortunately I can't remember if it was an add or a delete, nor can I remember whether it was a forward or reverse zone that was missing, all I remember is that both had to be present for the dynamic update to work. This was all rather a long time ago now but hopefully the log file will point you in the right direction.

[#5 · Accepted solution]

I decided to beat up my laptop a bit with releases, renews, and changing the Windows client DNS update settings.

What I found is that a DHCPRELEASE does in fact prompt the DHCP server to send a removal request to the AD DNS server. However, it only logs (shows up in SYSLOG) if the removal is successful. It does not appear to log at all if the removal is refused by AD DNS unlike adding records. If adding a record fails, it generates a SYSLOG message stating "Unable to add..." the record, but there is no counterpart for removal. This is a bit of a frustrating oversight in my opinion.

The root cause seems to be both clients and the DHCP servers updating the records. Looks like I have to work with our SA team to get the client updates disabled.

[#6]

Ah, yeah, what I've found in the past is that you need to decide whether to allow Windows clients to do their update themselves or whether the DHCP server does it. You can use option 81 to specify this, but even setting it so the DHCP server does the updates, I found that in some cases Windows clients still try to update DNS themselves. What I found is that on the initial DORA, the DHCP server would do the update but when the client does a renew at 50% of the lease time, the client would send a DDNS update itself, it kinda "forgets" that option 81 was supposed to switch that off. Again this was absolutely years ago when I discovered this, and may have been "fixed" by subsequent versions of Windows, but what it did to me is re-inforce the need for "allow-update" ACLs - so I always have an ACL now that prevents clients updating DNS and only allows DHCP servers and Windows Domain Controllers (and other servers like SQL that need to do DDNS).

What I do see now are thousands and thousands of "update denied" messages on the DNS servers, but I know that DHCP server is updating sucessfully so I don't really care if the client updates are being denied. Of course, if you have statically configured devices too (such as application servers), Windows by default will also be trying to register the host name every 24 hours regardless of option 81, so it makes sense to employ an ACL anyway.

If you have both Windows clients AND DHCP servers updating DNS then you will get into an awful mess. Windows is notorious for registering entries and not removing them, which is why Microsoft introduced DNS scavenging, but that causes yet more problems in environments where you have DDNS update optimisation enabled (so DNS record timestamps do not get updated and scavenging deletes valid records), I could go on and on and on about all of this as I've been doing this stuff for years! :-) Don't get me started on DHCIDs and docking stations.