Microsoft DHCP does (not) GSS-TSIG updates to Infoblox

[#1]

Hi, we run Microsoft DHCP server doing GSS-TSIG updates for PTR-Records to Infoblox DNS Server. After a time which cannot be specified (on high load DHCP earlier than on low load) the signed updates fail. The Infoblox DNS-Server answers with an RCODE:1001 (9, NotAuth, Server Not Authoritative for zone) Shouldn't that be something like BADKEY to tell the MS-DHCP to ask for a new TKEY? Does anyone know what indicates renewing TKEY? PS: We run NIOS-8.0.3 and Windows 2008R2 best regards Roland

[#2]

What do the logs from the DNS server say at that time, that would be helpful in getting to the issue? Also, do you mean that the same server which accepts the updates till now is suddenly responding with NOT AUTH? Was there any configuration changes made so as to delete the zone itself or change the primary

[#3]

Hi,

thank you for the help.

We just see "update denied" in syslog and "no auth" in traffic capture on MS-DHCP.

... no change in DNS-config.

best regards

Roland

[#4]

Hi Roland,

I would recommend reviewing the DNS configuration file and ensuring the update falls in the same view(if it has multiple views). and the server is indeed primary for the zone (look for "type master" or if a slave config look for update forwarding)

Regards,

Syam.

[#5]

Microsoft DHCP servers sending GSS-TSIG updates to Infoblox DNS servers has been flaky since Server 2003.  I've had a couple tickets open for this over the years.

Although our usual failure mode generates [BAD KEY] messages in the Infoblox syslog, the results are about the same as what you list.   At some point, the MS DHCP server stops negotiating the keys correctly with the Infoblox DNS server.  Sometimes a restart of the MS DHCP service will trigger a correct update, and sometimes a reboot of the Windows box will fix it. 

The last time I got Infoblox and Microsoft to talk about it and go through packet captures, it was that the Key roll over conversation all happened, Infoblox box started using the new key, and the MS box never switched for some reason.

Somewhere in late in the 6.X line (I think) of NIOS it got much better.  Infoblox put in some code that greatly reduced the issue but we have seen it in 2003 2008 2008R2 and 2012 and all the way through the 6.x 7.x and 8.x versions of NIOS.

Once a MS DHCP server starts doing this, it rarely quits for good.  I started playing with this again a year or so ago, after we turned on multi master DNS on Infoblox.  It seems to be locked to something between the two specific "OS's".  Making the DHCP server send its updates to a different Infoblox master would at least have the same affect as a restart of the services.  I never got much further and have not ever got back to take the time to really dig into it again.
If I remember correctly, there also was some speculation that if the account that the Infoblox server had its keytab file exported from, was in a different domain (same forest) as the DHCP server that it seemed to have the issue more often.
  I had some monitoring of the syslog for a while when it was bad, but it’s difficult to set a good threshold as service restarts of DHCP or DNS can trigger some BADKEY messages while keys expire or are re-negotiated .   So now it’s more of a best effort or I just add the DHCP server's IP to a allow ACL until it can get rebuilt.  It just depends on the frequency of the problem and the needed security of the environment.

[#6]

Hi Dan,

sorry for the delay ...

Thank you for working out.

I will try to get a solution with microsoft.

best regards

Roland

[#7]

Hello Roland,

I want to ask if you did find a solution with Microsoft?

Best

[#8]

no ;-(

[#9]

Once a MS DHCP server starts doing this, it rarely quits for good.  I started playing with this again a year or so ago, after we turned on multi master DNS on Infoblox.  It seems to be locked to something between the two specific "OS's".