I have a query about AD DNS records.
We are having random connectivity issues with a couple of Domain Controllers with cross forest authentication/lookups.
We have a 2 way forest trust between the two AD Forests, with DNS conditional forwarders configured for name resolution.
In the target forest we have 4 x Windows 2008 R2 Domain Controllers all with AD Integrated DNS installed.
When I do an NSLOOKUP on the TARGET domain or check the Name Servers tab on the DNS Zone, I see 5 records being returned instead of 4 x AD DNS servers.
The extra DNS entry of USDC500 is a legacy AD/DNS server that is no longer on the domain, but a DNS A record was created to point it to NADC001 just in case we had applications hardcoded to use USDC500.
This maybe a stupid question but is this an acceptable way to configure our primary DNS zone or handle AD authentication? We have problems enumerating group memberships across Active Directory Forest for authentication and trying to rule out DNS.
Forum info: http://www.activedir.org
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx
AD DNS query
- 683 Views
- Last Post 04 June 2018
If the two forest domain controllers are wide apart, you might be able to use Cross-Forest DCLocator process optimization:
I still need to revive my cross-forest authentication post, but this one (creating the trusts) uses the exact same methodology
In short, your cross-forest DCLocator process can use site-specific domain controllers - if the site names between the two forests match up. You can control which domain controllers will respond to the first lookup from
forest1, based on the site-location of the querying computer in forest1. If forest2 has a site with the exact same name it will prefer the servers in that site.
if you look at the query that I took from a WireShark when performing a cross-forest lookup (DClocatorProcess)
(192.168.x.x is Forest1 - called AzureStack.local - 172.16.5.x is Forest2 - sourcead.local):
192.168.200.67 172.16.5.27 DNS 125 Standard query 0x6eb5 SRV gc.tcp.Default-First-Site-Name.sites.sourcead.local OPT
<if that DC does not respond it will go to global zone>
192.168.200.67 172.16.5.27 DNS 125 Standard query 0x6eb5 SRV
172.16.5.36 192.168.200.67 DNS 215 Standard query response 0xb594 SRV _gc.tcp.sourcead.local SRV 0 100 3268 WIN-8B47PF72NID.SOURCEAD.local SRV
0 100 3268 DC01.SOURCEAD.local A 172.16.5.27 A 172.16.5.36 OPT
192.168.102.5 172.16.5.27 CLDAP 220 searchRequest(56) "<ROOT>" baseObject
What we see is that the first name-query was towards a site specific SRV record, if that DC does not respond (or the site itself does not exist), the next query goes to the "global" zone that contains
all writable domain controllers (by default).
What I did was create an empty site called “local” in my SourceAD (the target forest):
I enabled auto-site coverage for one of my DC’s in a custom GPO (so i control which DC will respond on the site-specific DNS lookup):
This allowed my custom DC (or DC’s) to register the site specific records in DNS (net stop netlogon & net start netlogon - force registration of these records):
Inside my sourceForest (forest1), I changed the Default-First-Site-Name to “local” and rebooted the entire thing to ensure all servers would recognize their new site. Obviously waiting
for 8 hours or so would help also. In your case you probably want to name the "local" in the target forest to match the site name where you perform your query from.
After that I see the following in the traces:
172.16.5.27 DNS 125 Standard query 0x6eb5 SRV _gc.tcp.local.sites.sourcead.local OPT
172.16.5.36 192.168.200.67 DNS 162 Standard query response 0x1aa2 SRV _gc.tcp.local._sites.sourcead.local SRV 0 100 3268
DC01.SOURCEAD.local A 172.16.5.36 OPT
As you can see, the stack now queries for the specific “local” site and my DNS server responds with the server that is covering this site, and the next calls in the trace are the actual
LDAP binding to that specific DC.
So you can control which domain controller should respond to cross-forest site requests.
Note that just querying A records on a "domain-name" does not by default implies that the response is
"all the covering domain controllers for the DCLocator process". The fact that the A record for zone sourceAD.local is hosted by all domain controllers, does not imply they have their SRV (kerberos and LDAP) records registered and thus are responding
to DNS queries..
in order to validate which domain controllers respond to your LDAP/GC query depends on these SRV records that are inside the _msdcs DNS zone, their record priority and weight. If these
are equal an LDAPPING is sent to all responses and the first/fastest DC to respond will handle the call.