promoting a domain controller across firewall

I have ServerA in LocationA that I want to run dcpromo on it and make it a DC, but I have to establish communication to the Domain Controller ServerB in LocationB.

ServerA is configured with its DNS server set to the IP of the router forwarding DNS to ServerB.

I have 53 tcp/udp, 88 tcp/udp, 135 tcp, 389 tcp/udp, 445 tcp/udp, 636 tcp/udp currently NAT'd to the main DC.

example of router config:
ip nat inside source static udp 88 88 extendable
ip nat inside source static tcp 88 88 extendable
ip nat inside source static tcp 445 445 extendable
ip nat inside source static udp 445 445 extendable
ip nat inside source static udp 135 135 extendable
ip nat inside source static tcp 53 53 extendable
ip nat inside source static udp 53 53 extendable
ip nat inside source static tcp 135 135 extendable
ip nat inside source static tcp 636 636 extendable
ip nat inside source static tcp 389 389 extendable

If I try to do a nslookup from the ServerB it can resolve, but not the internal domain.

When I run dcpromo I'm getting this error:

The following error occurred when DNS was queried for the service location (SRV) resource record used to locate an Active Directory Domain Controller (AD DC) for domain "":

The error was: "This operation returned because the timeout period expired."
(error code 0x000005B4 ERROR_TIMEOUT)

The query was for the SRV record for

The DNS servers used by this computer for name resolution are not responding. This computer is configured to use DNS servers with the following IP addresses:

Verify that this computer is connected to the network, that these are the correct DNS server IP addresses, and that at least one of the DNS servers is running.

 The records exist in ServerB's DNS and can be queried.  What I don't understand is how I can query say, or, but not resolve the from ServerA using ServerB's DNS.

Who is Participating?
Bruno PACIIT ConsultantCommented:

If your NATing routeur is not able to translate IP addresses inside DNS answers youll never be able to make it work.

NATing the IP address of the DC/DNS server in location B is not enough. That only permits your DNS requests to reach DNS on location B but then, the DNS in location B sends back a DNS answer containing real IP address of the requested DNS name.
When you receive the DNS answer in location A, your NATing routeur make things so that the IP packets containing the answer comes from the NATed IP address but probably not made any changed on IP address contained in the DNS answer inside the IP packet.

So you receive an answer that give you IP addresses you can't reach...

To check this, did you try to ping serverB from serverA using the FQDN name ? What is the IP address returned ?

Have a nice day.
One of the problems that your are having is the number of DNS entries that need to be added for a domain controller in active directory. I have temporarly taken a server to the required subnet, made the gateway and dns be the domain controllers IP, dcpromoted it there, then taken it back and reset the DNS and manually updated the local DNS.
Bruno PACIIT ConsultantCommented:
By the way,

You have NATed the TCP 135 port on your routeur. This is for RPC dialog but RPC TCP 135 port is only the "calling" port...
NATing the TCP 135 is not enough for RPC.

Here is a description of RPC dialog :

1) The RPC client send an RPC request on port TCP 135 of the RCP server.
2) The RPC server launch a new listening process on a TCP port dynamically chosen, usually the first unused TCP port above 1024. This dynamically TCP port is never the same because it depends of other RCP dialogs already open at this time.
3) The RPC server answer to the client to accept the RCP request and giving the client the number of the dynamic TCP port to use to continue the RPC dialog.
4) The RPC client close the RPC sessions on port 135 and open a new TCP session on the dynamic TCP port given by the RPC server.

So, to allow RPC dialog through a firewall or through a NATing routeur you have to :

a) Restrict the dynamic TCP port range used by the server for RPC. This can be done by addind some registry keys on the server to reduce the TCP port range usable for RPC. As an example you will restrict RCP server to use only TCP port from 1024 to 1124.
b) Add NATing rules on routeur to NAT TCP 135 and TCP 1024-1124 to the RPC server.

Have a good day.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

LrdKanienAuthor Commented:
I'm still trying to wrap my head around this:

When you receive the DNS answer in location A, your NATing routeur make things so that the IP packets containing the answer comes from the NATed IP address but probably not made any changed on IP address contained in the DNS answer inside the IP packet.

NATing router makes it so that the IP packets answer comes from the NATed IP, which would be the  I get that part.

But the probably not made any change  on the IP address contained in the DNS answer....

I don't get ^^ part.  Today I will test with some ICMP packets and give you the results.  

What about setting the host to contain an entry for the FQDN for the routers IP, which is NATed?
Bruno PACIIT ConsultantCommented:

Sorry, my english is poor I my explanations are hawful..

Well, let me give you an example:

Let's say your AD/DNS ServerB on location B has the IP address Let's say it is a DC for "".
Your ServerA is in location A, it has the IP address
You have a NATing routeur between these 2 locations. This routeur has a NIC on each subnet, one in locationB and one in locationA.
The routeur IP address for locationA is

All NAT rules are made so that any IP packet coming from ServerB to serverA is received by ServerA as it was coming from IP Address.

On ServerA you have configured your IP settings to use IP address as a DNS server.

OK. So now what happens when ServerA want located the DC of "" domain ? Let's suppose your want to ping the name "" from ServerA:

1) To ping the name "" ServerA needs to resolve the name to obtain the matching IP address. So ServerA send a DNS query to for "" name resolution.
2) The DNS query reaches the NATing routeur on The routeur looks at its NAT rules and change the destination IP address on the IP packet header with and transmit this new IP packet on locationA subnet.
3) The new IP packet reaches ServerB at
4) ServerB take the IP packet and read it. The content of the packet is a DNS query for name "". ServerB gives this request to its DNS Server service.
5) The DNS Server service looks in the "" DNS zone and find the host record "serverb". The IP address associated with the host record is "".
6) The DNS Server service send a DNS response saying that "" is resolved as This DNS answer is included in a new IP packet. The sender IP in this packet header will be because it is the IP address of ServerB where the DNS service is.
7) This IP packet reaches the NATing routeur.
8) The routeur looks at its NAT rules and then change the sender IP address in the packet header so that the IP packet comes from BUT ONLY THE PACKET HEADER IS CHANGED. The NATing routeur do not interpret the IP packet content and do not see that it is a DNS answer. It do NOT changed the content of the DNS answer.
9) The IP packet reaches ServerA.
10) ServerA open the packet to get the content. The content is a DNS answer to the DNS query previously sent. The DNS answer says that "" has the IP address
11) ServerA then tries to send ICMP PING packets to This IP address can not be reached..

Is it more clear ?

In fact the NATing routeur acts as a postman that would changed the address written on the envelop but do not open the envelop to change address on the mail...

Basic NATing routeur are not able to interpret DNS resquets in IP packet to change the DNS answers to replace real IP address by NATed IP address inside DNS dialog.
You have to check if your routeur is able to do that and if yes you have to activate this functionality.

Have a good day.
LrdKanienAuthor Commented:
The theory is now more clear, thank you for that explanation.

I am trying to only do a nslookup though, thus I don't understand why Step 11 would occur.  I can resolve from ServerA using ServerB as a name server, but I cannot resolve "".
Bruno PACIIT ConsultantCommented:

Does the "" zone exist in the DNS server ?
If it exist, is there a record named "same as parent" and what is the IP address associated ?
Bruno PACIIT ConsultantCommented:
Hi again,

Does your routeur have an integrated DNS function ? In this case it will probably intercept DNS queries sent to its IP address and redirect them to ISP DNS.
LrdKanienAuthor Commented:
Hi PaciB -

Both very good questions, thanks for asking.  Yes, the zone exists on the DNS server that the router is NATing packets 53udp/tcp to.  The zone "" has a same as parent A record of

As for the second question, I'm not positive.  I have a Cisco7100 router.  I do not think it is intercepting the requests though, because if I stop the DNS service and attempt a query it times out for both and  After starting it back up it resolves for  

I am also testing connectivity by using telnet from ServerA to ServerB across the NAT and I can see the established connection on 53 w/netstat -an | find "ESABLISHED" between the two servers.
I usually set up a vpn between the two subnets and then add dns entries on both sides. I do that with my router/firewalls and that seems to solve a lot of problems if both sides are the same company.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.