Reply

Windows Client DHCP and DNS Registration

Matt5150
Techie
Posts: 4
9844     0

(Disclaimer: Not the administrator of the Infoblox appliances)

 

We used to own DHCP and DNS when it was running from our Windows Servers, but it was taken over by the network team when the decision was made to go to Infoblox.  I do work closesly with the folks that administer these devices, and have some working knoledge of these devices.

 

 

I've been fighting a problem for years since we implemented Infoblox in our AD enviroment.  It took this long because we were not running into issues often enough and didn't have time / tools to figure out the source of the issues.

 

Issues:

 

From time to time, we would try to connect to a client machine via DNS name and would not have connectivity.  We would have to track down the client IP address and connect that way.

 

Details:

 

Windows devices with mutiple NICs (mainly laptops with WiFi NICs) sometimes can't seem to keep the currently connected NIC registered with DNS.  Out of 7000 workstations and laptops, I have about 150 at any given time that are reporting the previous IP or both the LAN and WiFi IP addresses in DNS.  It's not the same computers every time.  It seems to be random.

 

Previously we had TXT records enabled.  Before we disabled it we also had our VPN users (Citrix NetScaler) DNS entries being mis-reported by DNS after they were back in the office.  Usually 50 or more at any given time.  Due to political and technical challenges getting the Netscaler devices to use Infoblox for DNS, we disabled TXT records and that issue has gone away.

 

Disabling TXT records did worsen the issue of some devices registering multiple IP addresses with Infoblox.

 

So that leaves this 150 or so other machines on our LAN or WLAN networks that are not registering with DNS correctly randomly through the day.  Our network folks usually recommend we run IPCONFIG /RENEW, or reboot the machine to correct the issue.  This oddly is hit or miss. 

 

Reboot works %95 of the time.  IPCONFIG /RENEW works about %70 of the time.

 

 

 

Enviroment Configuration:

 

"DNS Dynamic Update" is disabled via Group Policy.

 

Computers are configured through Group Policy to run a VBScript at boot that disables the WLAN NIC when LAN connectivity is detected.  It automatically enables the WNIC when LAN is disconnected.

 

How this is being tracked:

 

Using an export of all computers and thier IP addresses from Surveyor, I use a PowerShell script to compare that IP for any computers reported to be currently connected, to the IP being reported from DNS.  Any missmatches are reported back with thier Name, number of times the computer has been reported, DNS IP/MAC/NIC name, Surveyor IP/MAC/NIC name, Current User, computer model, OS version.

 

 

Things I've tried:

 

A Scheduled Task is configured to run IPCONFIG /RENEW after any NetworkProfile 10000, 10001, or 4004 events.  The task is running the commands, but it doesn't seem to be having any effect.

 

Triggers were recently added to run IPCONFIG /RENEW 60 seconds after boot, then every 30 minutes after that (Troubleshooting / testing step).  This also doesn't seem to be having any effect.

 

I've swapped out the VBscript for a program based off PowerShell code, called WiFiSitter.  This also doesn't seem to causing any change to the number of DNS inconsistances.

 

Using PSEXEC to kick off a IPCONFIG /RENEW against all the computer's IP address on from the report, is about %75 percent successful.  The other %25 do not seem to update until rebooted.

 

 

My Quesion:

 

Is there anything from the description above that points to something we can reconfigure on the Infoblox appliance to solve this problem?

 

Entries in logs I should have the admins check?

 

Any other suggestions?

 

 

Thanks,

 

-Matt

 

Re: Windows Client DHCP and DNS Registration

Matt5150
Techie
Posts: 4
9844     0

*Surveyor is a power managment application we run which has a client on every PC.  The admin UI for this app gives us an easy way to lookup a current IP address outside of DNS, and also has the ability to export this information for all computers out to CSV for use with PowerShell scripts.

Re: Windows Client DHCP and DNS Registration

TTiscareno Community Manager
Community Manager
Posts: 340
9844     0

Hi Matt,

 

I believe you are running into issues due differing requirements for different systems. The main issue is that for systems with multiple NIC's, the default configuration only allows for one DNS record at a time and this is what is giving you your inconsistent behavior. One solution for this would be to place the different NIC's in their own zone. For example, wired interfaces could use corp.company.com, while the wireless interfaces would fall under mobile.corp.company.com.

 

The same configuration would also apply for your VPN users. Separating out the VPN interface from other interfaces for users who travel between the office and remote connections should also solve this issue for you and one benefit is that this would make it easier to identify where connections are coming from/to.

 

Following this type of implementation helps prevent multiple interfaces/connections from conflicting with one another, enabling you to use ISC TXT record handling mode which provides protection for DNS records, preventing other clients (or interfaces) from overwriting the record for a different client/interface.

 

Another option to look at is to enable GSS-TSIG authentication, which Infoblox does support. Separating out different interfaces/connections to their own zones provides a more reliable architecture as GSS-TSIG (which Microsoft uses) sort of masks when things are offline, but that is generally not an issue so it would be worthwhile to explore. Check out the NIOS Administrators Guide for guidance on how to implement GSS-TSIG.

 

Hope this helps.

 

Regards,

Tony

Re: Windows Client DHCP and DNS Registration

Adviser
Posts: 92
9844     0

Hello Matt,

 

Appreciate your detailed explanation of the issue. What Tony has proposed is a great suggestion which you may consider. In case if that’s not feasible, please read through this reply from a troubleshooting perspective.

 

There are few questions that I would still need to ask/confirm :

 

  • I am assuming that you are currently using Infoblox for both DNS/DHCP services. I am also assuming that the Infoblox DHCP server who grants leases for these clients are sending Dynamic DNS updates on client’s behalf to another Infoblox DNS server in the same ‘Grid’. Is that correct ?

 

  • When you say, “disabled TXT records”, did you change the TXT record handling mode to ‘No TXT record’ on the DHCP server ?  (Data Management -> Grid DHCP Properties -> IPv4 DDNS -> Advanced -> ‘TXT Record Handling’).

 

  • From the statement, ““DNS Dynamic Update" is disabled via Group Policy.”, I assume that the clients are NOT configured to update their DNS records to the server & it is the Infoblox DHCP server who does this task for the clients. Is that correct ?

 

I’ve seen some cases where clients fail to send DHCP option #12 during the lease request, which results in a situation where the DHCP server would fail to register its DNS records intermittently. If all my assumptions above are correct, you may ask your Infoblox server administrators to :

 

  • Pick up a test client, I’ll call this to be ‘testclient’. The zone to which DNS updates are pointed to is ‘example.com’. So this test should begin when you identify that ‘testclient’ is mapped to an incorrect IP address in DNS(inside ‘example.com’).

 

  • Let’s consider that ‘testclient’ received an IP address 10.10.10.10 from the DHCP server. But looking at the DNS server, its been mapped to an ‘A’ record with IP address 20.20.20.20(Let’s consider this was an IP address allocated to another interface of ‘testclient’ in the past).

 

  • Now, what you may need to look at is the ‘syslogs’ of the Infoblox DHCP server. Use a filter for :

     ‘Message – contains – ‘updating zone’’.

     

     ‘Message – contains – ‘testclient.example.com’’

 

  • This basically would return all the DDNS activities done for ‘testclient‘.

 

  • A packet capture during an successful renew would help you understand whether the client is indeed sending DHCP option #12 during an unsuccessful DNS registration. If the clients fails to include this option in the DHCP packet at any time, then that defines the problem.

 

  • A successful registration of DNS record right after a DHCPACK would look like : test.jpg

 

  • Now the question would be, what exactly has happened when the DHCP server attempted to update the DNS record right after the successful acknowledgement ? For this, you may lookup the syslogs :

 

     ‘Message – contains – ’10.10.10.10’

 

There may be a lot of results, but I hope your admin should be able to narrow down the problem here.

 

  • I see two possibilities here :

 

 An attempt to update DNS record is failing with a specific error (Reason’s vary depending on error. Depending upon the error, you may check out the Infoblox support site to see if there are any relevant KB articles. If not, please post what the error is or you may file a support ticket with Infoblox support team).

 

    Or

 

The DHCP server is not attempting to update DNS records intermittently – This is a problem which has to be investigated with data from your server.

 

 

I understand that it might be a pain to keep releasing/renewing IP addresses each time to get the DNS records successfully registered. I am so sorry to hear that you have been having this problem right from the time when Infoblox appliances were installed in your Infrastructure. This is where I would encourage you to engage Infoblox support to get timely help. Unless & until we investigate, we cannot be sure whether the problem is with Infoblox appliances or whether it is due to some external factors. But the good part about filing a ticket is, at least we can confirm whether its an issue with Infoblox not. That should be able to help you in eliminating Infoblox as a potential factor behind this problem.

 

Best regards,

Mohammed Alman.

Re: Windows Client DHCP and DNS Registration

TTiscareno Community Manager
Community Manager
Posts: 340
9844     0

Thank you for the follow-up. You are correct in that repeated renewal attempts are ignored. This is a measure of protection against DOS attacks, both intentional and unintentional (where a broken client floods the server with requests). To force this to do what you are trying to do on the client side, you may need to do an "ipconfig /release" and then an "ipconfig /renew".

Another option is to enable DNS updates upon renewal on the Infoblox side, but you would want to use caution with leaving this option enabled long term as that is a common DDOS attack vector (something which can even occur inadvertendly). When the "Update DNS on DHCP Lease Renewal" option is enabled, DNS would be updated every time you run the "ipconfig /renew" command like you are trying to test here. You can find instructions for enabling the option "Update DNS on DHCP Lease Renewal" in the section titled "Enabling DDNS for IPv4 and IPv6 DHCP Clients" in the NIOS Administrators Guide.

Regards,
Tony

Re: Windows Client DHCP and DNS Registration

Expert
Posts: 224
9844     0

I've seen various similar issues like you are encountering - modern networks have devices hopping on and off wifi and onto port replicators that have their own MAC addressess, which causes all sorts of issues with TXT records and DDNS. 

 

Unfortunately I feel that some of the default policies enabled in Infoblox are incompatible with modern networks. Infoblox isn't the only culprit, the other DDI vendors do the same. Here are a few things to consider:

 

* If you can, try to register your wifi interfaces into a sub-zone, you can still send the same DNS domain down to the client as used on the LAN interface, but set the ddns-domainname option to a sub-zone so that the wifi interface gets registered into a different domain - this allows you to continue having ISC TXT record checking enabled

 

* If you can't register the wifi connections into a sub-zone and they have to go into the same domain as the LAN connections (probably a political rather than technical reason) then you will need to disable ISC TXT records, however set it to the "check-only" option so that static records are still protected - for dynamic records they can stomp all over each other but static entries won't have a TXT record so can't be updated maliciously via a rogue DHCP update

 

* When you are jumping on and off the wifi, you will find that DNS still gets out of date, this is because Windows "remembers" if it has a valid lease or not from previously - so if you have a fairly long lease time on the wifi and jump off and back on later, Windows may just send out a DHCPREQUEST type lease renewal - because of this the DHCP server won't send a DDNS update. It will only work if the lease has expired and Windows sends a full DORA to get a new lease. To get around this you will have to enable DDNS on lease renewals - I wouldn't worry too much about enabling it, I have done it and the volume of DDNS updates is not high enough to cause a problem, although I would watch out for misbehaving/buggy clients that constantly send out lease renewals (e.g. Cisco VOIP phones).

 

* If you have a script that disables the wifi interface when plugged into the LAN, ensure it sends a DHCPRELEASE message before shutting down the adaptor - this means it will remove the lease and corresponding DNS entry, so the next time you jump onto the wifi it will update DNS because it'll use the DORA process to get a new lease. If you can't do it via Powershell, then use the ipconfig command but specify the wireless adaptor name so that it only releases the wifi lease.

 

* Some companies that use USB based port replicators find they they use their own MAC address, so ISC TXT record handling does not work at all well because clients are trying to register different names to the same MAC address as they move around the network. If you set TXT record handling to "check-only" then that fixes the problem. However other cusomers like to "pass thru" the client MAC address rather than use the port replicator's MAC, this is so that they can audit the devices, but then you have the problem with Windows remembering the lease and only sending a renewal and not updating DNS next time they dock. To fix that you need to enable DDNS update on lease renewals.

 

* For all of these scenarios people think that using a short lease time is the answer (to age out old wifi or LAN connections). It can help somewhat but even if it is only 30 minutes the problem is that help desks who are trying to RDP or remotely connect to client devices in response to tech support requests find that DNS is out of sync - it's very frustrating for them. It's also important that DNS is in sync for SCCM and software deployment technologies - if you have 10,000 devices that need to have a Windows patch applied and SCCM can't resolve half the host names, that is a massive security issue.

 

So whilst there are arguments for keep DDNS updates on renewals disabled, and having ISC text record handling enabled, the business has other priorities, and keeping their clients secure through regular patching/updates is far more important - I have found that things work much better when you change these policies away from their defaults. :-)

Paul Roberts
PCN (UK) Ltd

All opinions expressed are my own and not representative of PCN Inc./PCN (UK) Ltd. E&OE

Re: Windows Client DHCP and DNS Registration

Matt5150
Techie
Posts: 4
9844     0

@paulr wrote:

 

 

* If you have a script that disables the wifi interface when plugged into the LAN, ensure it sends a DHCPRELEASE message before shutting down the adaptor - this means it will remove the lease and corresponding DNS entry, so the next time you jump onto the wifi it will update DNS because it'll use the DORA process to get a new lease. If you can't do it via Powershell, then use the ipconfig command but specify the wireless adaptor name so that it only releases the wifi lease.

 

 


I tried this multiple ways, via the script, via task scheduler, it is just horribly inconsistent.

 

I can reboot a laptop at my desk 10 times, and 2 of those times it will stay with a DNS registration for the wirless.

 

If I have 100 laptops connected on LAN, but showing the WIFI addr in DNS.  I send a PSEXEC command to them to run a script in C:\TEMP that runs IPCONFIG /RELEASE followed 8 seconds later with IPCONFIG /RENEW, 10-20 of them will stay registered with the WIFI address.

Re: Windows Client DHCP and DNS Registration

[ Edited ]
bencuttings
Techie
Posts: 1
9844     0

DNS registration is a service, which allows the owner of a domain name to use his own name servers, which can match the domain name in question. If you are using Windows 10 and you are not able to browse websites and other contents over the internet then visit here <External Link Removed> to fix this problem.

 

<Moderator> Please do not include external links. These are frequently spam, malicious, or will become broken. Helpful information is always welcome when included directly in your post.

Highlighted

Re: Windows Client DHCP and DNS Registration

[ Edited ]
alistarsmith3
Not applicable
Posts: 0
9844     0

This is a wonderful Windows-based feature that most other DHCP servers doesn't handle too well.  Not saying either is wrong here, but the fact is that Windows DHCP servers DO tell the DNS clients to update A and PTR records when an IP address is obtained.

 

<External Link Removed>

 

<Moderator> Please do not include external links. These are frequently spam, malicious, or will become broken. Helpful information is always welcome when included directly in your post.

Re: Windows Client DHCP and DNS Registration

TTiscareno Community Manager
Community Manager
Posts: 340
9845     0

@alistarsmith3 wrote:

This is a wonderful Windows-based feature that most other DHCP servers doesn't handle too well.  Not saying either is wrong here, but the fact is that Windows DHCP servers DO tell the DNS clients to update A and PTR records when an IP address is obtained.


 

What you describe is not a function of the DHCP server, but in the DHCP client configuration. In the case of Windows based clients, that is controlled in their TCP/IP settings but as the original poster noted, DHCP clients are not always reliable in updating DNS. Because of this, best practice is to not even allow DHCP clients to update DNS and instead, have the DHCP server maintain this on behalf of the client. The DHCP server (speaking at least on Infoblox servers andwhen this option is enabled) will create the records in DNS when the client obtains a lease and clean it up when the client releases its IP, or its lease expires.

 

With the DHCP server updating DNS, there is no concern about records going stale but there is still a DNS record scavenging option for environments that do allow clients to update DNS and struggle with this issue.

 

Regards,

Tony

Showing results for 
Search instead for 
Do you mean 

Recommended for You