Welcome back. The Centrify client for UNIX/Linux/Mac does keep its own DNS cache.
This doesn't necessarily mean that your that there's a causal relationship between the timeouts you're seeing vs. what's in the DNS cache. As a matter of fact, you gain performance benefits based on what we do.
We would be better served by knowing what is the Apache/PHP app doing before we can make that assessment.
For example, it is entirely possible that you moved the FSMO roles in question, from serverC to serverA, however, serverC continues to be the only Global Catalog available.
Your app may be making a call like "Give me all users or all groups and bypass the cache" or maybe your app is querying attributes that we aren't actively caching.
You are passed the DNS layer at that point. You need to find out what's different about ServerC (I suspect that it's the only GC) vs the others.
Get it?
What to do next:
I would talk to the developer and find out what is the app doing and try to find out if there are enough global catalogs around.
adinfo --diag | more
you want to look at the domain diagnostics. You should be able to identify which machines are global catalog. Look for the "isGlobalCatalogReady" field under the domain controller name.
Domain Controller: dc.centrify.vms:3268
Domain controller type: Windows 2012 R2
Domain Name: CENTRIFY.VMS
isGlobalCatalogReady: TRUE
domainFunctionality: 5 = (DS_BEHAVIOR_WINSERVER_2012)
forestFunctionality: 5 = (DS_BEHAVIOR_WINSERVER_2012)
domainControllerFunctionality: 6
Forest Name: CENTRIFY.VMS
Site: Demo-Network
Subnet: 192.168.81.0/24
Server: DC (dc.centrify.vms)adinfo --sysinfo netstate
This command will show you info about your DCs, their ping, sweep information, etc.
===============Network State===================
Site Map
centrify.vms=>PreferredSite:Demo-Network, SubnetSite:Demo-Network
Domain Map
centrify.vms
dc: dc.centrify.vms
gc: dc.centrify.vms
forest: centrify.vms
state: alive
swept: 19 mins ago
Domain Controllers
dc.centrify.vms (192.168.81.10)
pinged: 19 mins ago
state: up
ping: 0.004409 secs
forest: centrify.vms
nbhost: dc
site: Demo-Network
flags: WCTKLG
Blocked Services: None
===============DC Statistics===================
dc.centrify.vms
Last Success: Wed Jul 27 19:03:25 2016
Last Failure: Wed Jul 27 05:46:57 2016
Successes: 373
Failures: 101
adinfo --sysinfo dns
This will show you information the current DNS servers and the cache (for academic purposes only, your issue is unrelated to DNS)
System Diagnostic =======DNS Servers State========== DNS Server Used: 192.168.81.10 DNS Status: Up =======DNS Server Info======= Last Sweep: Wed Jul 27 18:40:23 2016 Fast Sweeps: 1 Deep Sweeps: 43 Okay Sweeps: 44 Failed Sweeps: 0 Cache Hits: 957 Cache Misses: 6 DNS Flushes: 0 =======DNS Server List======= IP: 192.168.81.10 Status: Alive udpSuccess: 84 tcpSuccess: 44 udpNoSuchName: 0 tcpNoSuchName: 0 udpTruncations: 0 tcpTruncations: 0 udpIOFailures: 0 tcpIOFailures: 0 udpTimeouts: 0 tcpTimeouts: 0 udpFailures: 0 tcpFailures: 0 udpServerFail: 0 tcpServerFail: 0 lastQueryTime: Wed Jul 27 19:09:04 2016 lastDnsCode: 0 Average Time: 0.00104998 seconds IP: 192.168.81.11 Status: Alive udpSuccess: 48 tcpSuccess: 43 udpNoSuchName: 0 tcpNoSuchName: 0 udpTruncations: 0 tcpTruncations: 0 udpIOFailures: 0 tcpIOFailures: 0 udpTimeouts: 0 tcpTimeouts: 0 udpFailures: 0 tcpFailures: 0 udpServerFail: 0 tcpServerFail: 0 lastQueryTime: Wed Jul 27 18:40:23 2016 lastDnsCode: 0 Average Time: 0.00279184 seconds =======DNS Cache contents========== Hdc.centrify.vms=>dc.centrify.vms 192.168.81.10 S_gc._tcp.demo-network._sites.centrify.vms=>dc.centrify.vms:3268:100:0 S_kerberos._tcp.centrify.vms=>dc.centrify.vms:88:100:0 S_kerberos._tcp.demo-network._sites.centrify.vms=>dc.centrify.vms:88:100:0 S_ldap._tcp.centrify.vms=>dc.centrify.vms:389:100:0 S_ldap._tcp.demo-network._sites.centrify.vms=>dc.centrify.vms:389:100:0
Bottomline - it's not about DNS, it's about what the app is requesting and the environment. More information is needed, however this is a good start.
The current, supported version of Express is 5.3.x
R.P