Unsolved
This post is more than 5 years old
1 Rookie
•
91 Posts
0
2349
Problems with VNX and non-AD dynamic DNS Infoblox
We are having an issue with DNS that is affecting all 3 of our VNX boxes. none of them can update DNS with CIFS server info.
The problem just started Sunday, but there was an enterprise change to move away from Windows AD DNS to Bind-Based DNS using Infoblox servers.
The way it used to work was the datamover would register in DNS for the CIFS server and when the VDM/CIFS would fail over to another VNX, it would register in DNS dynamically and update the IP address. This was controlled by the SID of the CIFS server having permissions to update the record.
Since moving to infoblox, the records are not updating. The errors were:
dns_updateMessage: GSS-API minor error: Server not found in Kerberos database
DNS update ERROR: Primary name server not found while registering mtwnastest1.xx.xx.xx.edu
dns_updateMessage: gss_init_sec_context failed for target DNS@esgbloxgm.xx.edu
dns_updateMessage: GSS-API major error: Miscellaneous failure
To move to Infoblox, they imported all the DNS records as static records and created an ACL for IPs that needed to update records such as Windows clusters. At first troubleshooting one record, we just added the IPs for the CIFS server (source and destination) but that didn't work.
Then we tried changing the DNS server parameter to update mode 1 (unsecure updates) from the default setting which was 2 (secure updates) still wasn't working. We did stop getting 3 of the 4 errors. We were just getting:
DNS update ERROR: Primary name server not found while registering mtwnastest1.xx.xx.xx.edu
Last thing we did was add ALL the IPs including the control station and all IPs on the datamover to the ACL and it was able to update DNS and the errors went away.
The only problem is with replication/failover. for example, I used a test server mtwnastest1. it had an ip of 10.173.x.x on the source and after failing over it updated the DNS record with 10.15.x.x but it LEFT the old 10.173.x.x address. This didn't happen with AD DNS.
What are other people using for DNS with VNX with replication/failover? When are secure DNS updates required?
umichklewis
1.2K Posts
0
February 19th, 2014 07:00
In a previous environment, we used traditional BIND DNS as authoritative for our domain, and set the Domain Controllers to be slaves. This worked reasonably well, but still resulted with inconsistent results after a VDM failover. We solved it by provisioning a brand new subnet, and making the Domain Controllers authoritative for that subnet. We put the source and target VDMs on that subnet and trunked the VLAN to the remote site, so that the same IP was available at the remote location. This worked well, until the VLAN traffic made the solution untenable to our network team.
The fallback solution was similar to yours, we changed the DNS record for the CIFS server to include the source and destination IP addresses (10.220.74.x and 10.44.74.x) and lowered the TTLs. Sadly, I did not have a chance to test this while I was still there.
mjzraz
1 Rookie
1 Rookie
•
91 Posts
1
February 20th, 2014 14:00
We appear to be working as well as we were with AD DNS now. Once we added all the CIFS server IPs and the control station and SP IPs for good measure to the ACL for modifying records, things started working on our other 2 VNX systems.
With these systems I hadn't change the update method for DNS from the default (parameter 2) secure updates. I changed back the one we had switched to unsecure updates (1) and tested failover. This time NO duplicate IPs on the DNS records. Perhaps the system that is "releasing" the CIFS server needs permissions to take away the old IP? Not sure, but It looks like we are back to the way AD DNS works.
I want to test a little more but on the first failover the IP on the DR system came up in DNS super fast and client connections resumed working. I'll have to see if we can change the TTL on individual records for the important systems