Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have two independant domains I need to establish a one way non-transitive trust between. Domain 1 (clientdomain.local) has native subnet of 192.168.4.x and Domain 2 (hosted.local) has native subnet of 172.24.19.x.

The two networks are connected via a VPN through a firewall. The problem is that the 192.168.4.x subnet is already in use in the hosted environment so we have them NATing to 6.6.200.x

I would normally setup DNS Stub zones on each domain pointing to the DC of the other domain and then setup my trust. In this case, I can do that but the records for clientdomain.local show up with 192.168.4.x addresses and I need them to resolve to 6.6.200.x addresses.

I tried to add a new Primary lookup zone and manually add A records for the DC's and and A record for clientdomain.local but although name resolution works for the DCs if I use the FQDN, I can't get resolution to work for the domain itself. Of course this is necessary since when you setup the trust, it asks for the domain you're setting up a trust with and tries to contact it.

Any ideas of how to "trick" DNS into reporting back one of the 6.6.200.x addresses for clientdomain.local?

share|improve this question
Can you edit your question and paste in an nslookup clientdomain.local? – Mark Henderson Jul 29 '10 at 21:34
up vote 0 down vote accepted

Your best bet is to look at the netlogon.dns file from the %SystemRoot%\system32\config folder of a clientdomain.local domain controller and base your standard primary zone on that information. Edit the IP addresses in that file to match your NAT'd subnet (Who came up with, anyway? I guess you'll probably never need to talk to the US Army, eh?), remove any references to DCs you don't want to talk to from the hosted environment, and create the appropriate records in a standard primary zone on a hosted.local DNS server. That should get you what you need. Just remember that, if significant changes occur in the clientdomain.local domain you may need to re-import the file.

For the domain itself you'll want an "@" host record (blank hostname) for each of the IP addresses of the DCs that should resolve for the domain's name. (In the DNS records created by the Netlogon service all of the IPs assigned to all of the DCs would be listed in the "@" record for the domain. You can get by with fewer, though.)

share|improve this answer
OK - DNS is now working - thanks Evan - I didn't need to mess w/ the netlogon.dns files (yet) but I added the "@" records and now I can resolve the clientdomain.local to an IP from the hosted.local domain. But I'm still not out of the woods. I open AD Domains and Trusts on my hosted.local DC and open the properties of the hosted.local domain. Go to Trusts tab, click New Trust, enter clientdomain.local and click next and get The name you specified is not a valid Windows domain name... and it won't let me continue. Any ideas what I'm missing now? – Bryan Nikkel Jul 30 '10 at 19:10
@Bryan Nikkel: You'll need the SRV records in the "_msdcs.clientdomain.local" subdomain to get a trust relationship to work. When you initiate the creation of the trust relationship a query for "_ldap._tcp.dc._msdcs.clientdomain.local" will be made, and if no good response is received the trust relationship creation is going to fail. – Evan Anderson Jul 30 '10 at 20:41
That did it. I wasn't sure which SRV records I needed so I just duplicated the whole _msdcs structure that was there for the hosted.local domain. Now my trust is working as it should. Thanks Evan. – Bryan Nikkel Aug 3 '10 at 14:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.