DNS request timed out. Timeout was 2 seconds. Server: Unknown

DNS request timed out. Timeout was 2 seconds. Server: Unknown

If you are experiencing this problem – seeing this small message followed by correct DNS resolution, using nslookup – then this blog is for you. Here I will show how the problem was fixed. With it a bunch of other problems as well…

So here is the initial setup: we have two Windows Server 2008 R2 servers configured as AD DC and DNS holding each one primary AD-integrated zone for their respective domains. Two separate forests with single domains. Server Glasgow holds domain contoso.internal. Server London holds domain tailspin.com.

The servers are in separate subnets, connected via router. Ping to their respective NICs is successful. We configure two conditional forwarders for each domain, and there come the problems.

In the image below server Glasgow.contoso.internal is being configured with a conditional forwarder for domain tailspin.com and the external domain’s DNS server. Pay close attention to the "attempting to resolve…" and "Validating…" states. Later the Server FQDN will be LONDON (mind you that is NOT a FQDN, but Microsoft knows better), and Validated will say something unreadable about "unable to validate…"

Still after this exercise if you click on OK you will be able to resolve London.tailspin.com to its correct IP address. What you actually cannot do is resolve tailspin.com. And vice versa from the opposite domain: Glasgow.contoso.internal can be resolved, contoso.internal not.

Has anyone paid attention to the remark on the bottom of the image? "blah, blah, if the appropriate reverse lookup zones and entries are not configured". Now that is great news. Since I was using a pure IPv4 routing (and obviously the conditional forwarders contained IPv4 addresses) I configured IPv4 reverse lookup zones. Alas to no avail. Also this timeout of 2 seconds before resolving the computer names was irritating. There were no appropriate answers at Microsoft’s online support so I had to learn the hard way by error and trial: if you haven’t deactivated the IPv6 protocol on your server you must
create an IPv6
reverse lookup zone and the PTR record for the NS record as well. Here is the difference in the second image:

The implications of not fully configured DNS settings might be very annoying. Domain replication outages, between domains in the same forest could be expected. Well, generally everything else that relies on FQDN-based network flow…

In my case I couldn’t establish a forest trust between the two forests before eliminating the above problem: the error from the Trust Wizard was "The name you specified is not a valid Windows domain name. Is the specified name a Kerberos V5 realm?" You can follow all the conversation under http://social.technet.microsoft.com/Forums/en/winserverDS/thread/bb7af3f4-6c05-4986-a001-283cbb023243 but essence is, before you start creating any sort of domain or forest trust, make sure that you can query is displaying at least one SRV and one A record (more is for redundant DNS servers):

(1) Type nslookup, and then press ENTER.

(2) Type set type=all, and then press ENTER.

(3) Type _ldap._tcp.dc. _msdcs .trusting.domain.com and then press ENTER.

(4) Type _ldap._tcp.dc._msdcs.trusted.domain.com and then press ENTER.

If no records are listed under (3) or (4) don’t even start creating a Microsoft AD trust.

The moral of this story is – at least for me – if you are going to use IPv6 in your environment, manage it at full extent. If not, disable it totally. Leaving it "on its own" will bring you loads of gray hair. I just remembered one more IPv6 connected case when installing Exchange in a productive environment. But that’s another story.