Hi - first post, pls forgive any improprieties, they're unintentional.
We have a set of mobile PCs which connect via Verizon when in the field, but via wifi when the vehicles in which they are mounted drive into the facility. Layered on top of those connections is a virtual adapter implemented by a NetMotion VPN client. The wifi and NetMotion connections employ Infoblox DHCP scopes to obtain their IP and network settings (the Verizon connections are managed separately via a private IP setup with Verizon, and don't come into play in this issue).
The wifi scope has a lease length of 8 days; the NetMotion client scope has a lease length of 2 hours. Both have IPv4 DDNS settings "Enable DDNS Updates" and "Update DNS on DHCP Lease Renewal" checked. Note, the wifi scope is shared among these devices and others, so we can't disable DDNS updates for that scope.
The network adapters in Windows are set with "Update DNS" unchecked for the wifi adapter, and "Update DNS" checked for the NetMotion virtual adapter (that's a carryover from before we transitioned the DHCP to Infoblox, when we wanted the Windows DNS client enacting the DNS change - though we don't think it should be needed, since the Infoblox DHCP range should be updating it anyway).
Our intention in setting the scopes this way was that the NetMotion IP would be present in DNS for the device (would "win"). The thought process was that yes once every 4 days, the wifi lease would expire and yes, DNS might get updated to the wifi IP temporarily, but within an hour at most, the NetMotion lease would expire/renew, and the IP would be updated back to the NetMotion IP for the device. We could live with that max 1 hour/avg 1/2 hour window of the "wrong" IP in DNS.
But that's not what we observe. The devices sometimes seems to initially get the NetMotion IP in DNS, but as soon as the device roams onto wifi, the wifi IP is posted in DNS, and it stays, it doesn't get updated back to the NetMotion IP, even though we can see the NetMotion-related leases expiring and updating (in the Infoblox syslog).
Thoughts? Are there priorities negotiated between the scopes in terms of DDNS updates, which one "wins"?
Seems to me it would work if we disabled DDNS updates for the wifi scope - but we would have to figure out how to move those devices to a different scope - which would involve a lot of AP config etc.
Any thoughts appreciated.
Solved! Go to Solution.
09-17-2015 05:17 AM
I've seen a similar situation at one of my customers. I believe what's going on is as follows (quoting from a document I wrote for them, with additional comments interpolated):
When a laptop (or other DHCP client) originally requests and is granted a lease by an Infoblox DHCP server, that server also creates DNS records for the laptop based on the client’s hostname and its dynamically assigned IP address. Besides the A record and PTR record mapping the laptop’s FQDN to its IP address and vice versa, there is also a TXT record created that is associated with the laptop’s FQDN and in essence marks the newly-‐generated A and PTR records as being “owned” by that laptop. The data in the TXT record is based on the DHCP Client ID (DHCID) for the laptop, which is in turn normally based on the MAC address of the network interface used by the laptop to connect to the network (for example its wired Ethernet interface). If the laptop later tries to connect using a different network interface, e.g., via wireless instead of wired, then the MAC address will be different and thus the DHCID and the resulting TXT record value will be different as well.
[The important part:] By default NIOS refuses to modify existing dynamic DNS records if the new TXT record generated from the DHCID does not match the TXT record already present for the laptop’s FQDN. Thus even if the laptop gets a new IP address and can connect to the network through the new interface, the DNS data will continue to indicate that the laptop is connected using the original IP address. [This is true for as long as the original lease is in effect. Once the original lease expires then a new lease using a different network interface will update DNS without issue. What I suspect happened is that the client got its first lease and associated DNS update via the Netmotion scope. Then the Netmotion lease expired and the client got a second lease via the WiFi scope and a new DNS update. At that point if the client got another Netmotion lease the DNS update would fail until the WiFi lease expired--which would be a long time.]
This issue can be addressed by changing the "TXT (DHCID) Record Handling” parameter to the value “Check Only” instead of the default value of “ISC”. With the “Check Only” setting, NIOS will still verify if A, PTR, and TXT records are already present for the laptop, but will allow existing A and PTR records to be changed as long as there’s a TXT record present, even if the original and new TXT records don’t match. In other words, dynamic DNS updating is possible as long as the existing DNS records were apparently the result of a prior DHCP lease being granted for the laptop. For more information see the NIOS Administrator Guide, chapter 20, “Configuring DDNS Updates”, section “Configuring DDNS Update Verification”.
This parameter can be set at grid level by going to “Data Management” -‐> “DHCP” -‐> “Grid DHCP Properties” -‐> “IPv4 DDNS” -‐> “Advanced”. It can be set for an individual DHCP server by going to “Data Management” -‐> “DHCP” -‐> “Members/Servers” -‐> “Members/Servers” -‐> [select member] -‐> “Edit” -‐> “IPv4 DDNS” -‐> “Advanced”. It cannot be set on an individual DHCP scope/range.
09-17-2015 08:50 AM - edited 09-17-2015 08:58 AM
Interesting! Just curious, is this standard behavior (e.g., RFC-defined)?
FHecker, do you know whether an explicit DNS registration on the client "overcomes" this DDNS constraint? It's been suggested to me that I schedule an "ipconfig /registerdns" ... I don't think that would work, because there's no way to restrict it to just the NetMotion virtual adapter's lease - and so even if each lease renewal/DNS registration is effective, whichever adapter's lease goes last would "win". But I may be able to script DNS registration of just the NetMotion adapter's IP ... would such a client request succeed, or be blocked by the TXT record restriction?
09-17-2015 08:56 AM
Btw, your explanation makes sense out of why a small percentage of devices sometimes get the NetMotion IP in DNS ...
They usually boot their device before driving off for the day - and so it gets on wifi first, then NetMotion, and the wifi IP would "win". But if the device is booted when they're in the field, they'll connect via Verizon (no DHCP scope involved, so no DDNS), then NetMotion fires up (using an Infoblox DHCP scope, which registers the NetMotion IP in DNS). At that point, even if they roam to wifi and get a wifi IP, I suspect the NetMotion IP would persist because of the TXT record (unless both the wifi and NetMotion leases happened to expire at the same moment).
09-17-2015 10:29 AM
I will defer to others for a more complete and definitive answer, but my understanding is that dynamic DNS updating is (still) defined in RFC 2136, which dates from 1997, and that either that RFC or the original ISC DHCP implementation specify only the "ISC" behavior, i.e., not applying the DNS update if a TXT record exists and does not match the new TXT record. I believe the "Check record only" option is Infoblox-specific.
Interesting! Just curious, is this standard behavior (e.g., RFC-defined)?
Again, I'll defer to others, but: Is your DNS server actually configured to accept DNS updates directly from clients? If not then I don't see how this would work in any case. Even if it is so configured, I suspect it would encounter the same TXT record issue I previously discussed.
FHecker, do you know whether an explicit DNS registration on the client "overcomes" this DDNS constraint? It's been suggested to me that I schedule an "ipconfig /registerdns" ...
04-14-2016 10:42 AM
I have a kind of similar issue running in on my Infoblox which is hosting DHCP and DNS services.
I have a client which first connects to wired gets an IP address and gets registered on DNS
Post this he moves to Wireless get an iP from new Scope and I can see him getting registered on DNS as the A record which was created corresponding to his hostname in Infoblox now is modified and has the new IP address of wireless.
However when he moves back from Wireless to wired the DNS records are not getting updtaed.
I have checked the TXT record setting and its set to "Check only"
Please if you can help
04-13-2019 01:29 PM
I am facing same kind of issue.
Client leases wired IP from one of the grid member and wireless from grid master (both serves dns and dhcp services) , when I switch from wireless to wired, dns record is not updating. When I look at the audit log I could see DDNS update from both dhcp server at the same time for wireless and wired IPs but always wireless wins. I also noticed, after 4 hours (since the lease time is 8 hours) the same pattern appears in the log.
11-13-2019 12:28 PM
I am having the exact same issue as daboochmeister. We have netmotion infoblox and clients on vehicles that switch between netmotion and wifi networks. A records do not get updated correctly when clients switch networks. I know this is an old post and it was marked as solved but it doesnt seem like the marked answer is the solution.
We have Check Only selected but it doesn't change the behavior. Clients that switch network either have no A records or the A record point to an IP that does not reflect the current IP of the client. DNS will only update the A record on lease creation. It does not update on lease renewal even when switch networks. (There is a check box in the DHCP IPv4 DDNS settings that if checked will update the A record on lease renewal, however we which we were told is only for a specific reason and not for solving our current problem). Leases will only get recreated if they expire or are released by the client. So depending upon the lease duration there could be a long time when a client either does not have an A record or the A record is incorrect.
daboochmeister did you ever find a solution to the problem?
11-21-2019 03:07 PM
- If a client does not expire its lease or release it before aquiring a new one via different relay but from the same ip-helper, technically the DHCP server is simply not privileged to expire that lease AND/OR remove associated records.
- Since you've mentioned Check-Only, assuming that DDNS in your environment is the sole responsibility of the DHCP server and client updates are denied by an update-ACL, IF the client uses its same interface to aquire a different lease from a different network segment, you can configure "One-Lease-Per-Client" on the Infoblox side for the server to forcefully expire leases that are no longer expected to be Active on the same client's same NIC/MAC. Once again, "One-Lease-Per-Client" is interface specific and has nothing to do with the same client having active leases on a wired and wireless subnet at the same time, in which case those are obviously different MACs.
- For a client that may switch between network segments multiple times the same minute [believe me, I've seen those] without expiring/releasing their leases, you would definitely want "DDNS update on lease renewal" enabled along with the above.
- Additionally, you may want to consider separating DDNS updates for wired and wireless networks to different DNS zones [wireless.example.com && wired.example.com] for ease of administration and better control [Unless you have reasons to believe otherwise].