Hello,
We are having a weird problem, and we're trying to track down the culprit. The evidence to this point suggests that Centrify may be affecting the DNS resolution on the entire system and not just AD related calls as one might expect.
Environment:
Centrify Express
CentOS 7
3 domain controllers reachable from this machine
1 of those domain controllers has the FSMO role for the domain (moved earlier in the week from another one of those 3)
FSMO used to be C, but is now on A
DNS servers are also the domain controllers
/etc/resolv.conf lists all three in an particular order, A B C
/etc/resolv.conf has 'options timeout:1' as well
Action:
We bring down machine C
Result:
PHP code executing in apache slows down dramatically, going from response times of 0.3 seconds to > 15 seconds
Action:
We bring machine C back up
Result:
PHP/Apache response times almost instantly return to normal
Action:
Leave domain controller C up, but block off all port access except for DNS
Result:
No impact seen
Action:
Block off DNS port access to domain controller C
Result:
Machine nearly instantly slows down again
Question:
Why would bringing down the tertiary dns server from resolv.conf impact the name resolution at all? The primary and secondary servers are up, functional, and entriely responsive via dig/nslookup/etc when queried directly from that node. Is it possible that Centrify intercepts the normal resolver flow and injects it's own (apparently out of date) opinion on dns server priority? I should mention that this series of tests was done on a machine where domain controller A would be the DC for this machine's site/subnet in AD and is listed in adinfo as the preferred/Connected DC.