DNS request timed out. timeout was 2 seconds. *** Request to self timed-out

Question

I am having an issue with one of my domain controllers (Server 2012 R2). It is a DNS server as well and it times out 100% of then time when attempting connect to either of the two trusted forests that are setup as conditional forwarders. There is also a
delay or a time out the first few times when attempting to resolve an external site such as google.com. The domain controller functions fine. All routing seems to fine, because I can telnet on port 53 to the trusted forest's DCs. They can even use the problem
DNS server to resolve hosts. It just does work from my controller to the other forest. Here is an example of what is happening.
> external.forest.dc
Server:  problem.local.dc
Address:  192.168.1.8
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to problem.local.dc timed-out
> external.forest.dc
Server:  problem.local.dc
Address:  192.168.1.8
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to problem.local.dc timed-out
Google will resolve eventually resolve
> google.com
Server:  problem.local.dc
Address:  192.168.1.8
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to problem.local.dc timed-out
> google.com
Server:  problem.local.dc
Address:  192.168.1.8
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to problem.local.dc timed-out
> google.com
Server:  problem.local.dc
Address:  192.168.1.8
Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:4006:808::1001
          74.125.226.67
          74.125.226.66
          74.125.226.72
          74.125.226.69
          74.125.226.68
          74.125.226.70
          74.125.226.73
          74.125.226.64
          74.125.226.65
          74.125.226.71
          74.125.226.78
The other DC works as it should:
> external.forest.dc
Server:  working.local.dc
Address:  192.168.1.7
Non-authoritative answer:
Name:    external.forest.dc
Address:  10.1.1.1
There is a firewall between these networks, they connect via campus fiber. I created an any rule to rule that out. I am thinking the DNS server is corrupt, but I cannot figure it out. 
Dcdiag /test:dns says everything is great.
Any suggestions?

Answer 1

Hi,
According to your description, my understanding is that the problem DC is configured with conditional forwarders to resolve names about other 2 trusted forests, and always times out. Besides, there is a delay or a time out the first few times when attempting
to resolve an external name.
Use NSlookup to confirm that if the conditional forwarder works. Open CMD on problem DC, type the command below and each line end with enter:
Nslookup
Server <IP address of the condition forwarder which used to resolve names on trust domain>
<name of the trust forest which you want to resolve>
If it works, try to increase time-out period:
Properties of Conditional Forwarders – Number of seconds before forward queries times out
– change the time.
If it doesn’t work, turn on exhaustive debugging mode. Open CMD on problem DC, type the command below and each line end with enter:
Nslookup
Set d2
Server <IP address of the condition forwarder which used to resolve names on trust domain>
<name of the trust forest which you want to resolve>
Post the result here.
Besides, for internet/external name resolving problem, we usually have another DNS server(except for DCs) which connected to Internet/external and used to resolve external/Internet names. And on DCs, configure forwarder and use forwarder to resolve external/Internet
names. If it is your case, check the forwarder setting on the problem DC, or use ping to test the network connectivity. Confirm that if the delay of name resolving caused by network delay.
Best Regards,
Eve Wang
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact
[email protected]