I am facing a puzzle:

My company has several branches, each branch's subnets have been defined in their own respective site, and each branch has its own RODC.

However, when pinging to the domain name (let's say, "example.com"), instead of resolving to the site's RODC, it resolves to the one of the main DCs on the Head Office.

AFAIK, when a computer on a site tries to resolve the domain name itself (e.g., when trying to access \\example.com\netlogon), it should resolve to the site's domain controller.

So, why am I seeing this behavior here?

Additional info:

  • The main DCs on Head Office are a mix of 2008 and 2008 R2
  • The RODC on the branches are 2008 R2

Any suggestion will be helpful. TIA.

More Information:

The problem was that the WAN link between Head Office and Branches are very slow (bandwidth costs a fortune in my country). There are several large files that we replicate through \\example.com\netlogon, and because some branch computers resolve example.com into the IP address of the Head Office DC, they're pulling those files through the slow WAN link instead of accessing the replica on the branch RODCs.

  • Why do you expect the behavior to be different and what issues is is causing? – uSlackr May 23 '12 at 12:09
  • Which DNS servers are the client using (probably set via DHCP)? The main office or the local site? – Jeremy May 23 '12 at 13:52
  • @uSlackr I have edited my question to explicitly state the issue. – pepoluan May 23 '12 at 14:34
  • @Jeremy I checked the branch computer, and apparently it uses them all (local RODC as 1st server, head office DC as 2nd server and so on). – pepoluan May 23 '12 at 14:35
  • Confirm your Active Directory sites are set up, basically listen to the two answers below, they have provided good information :) – Jeremy May 23 '12 at 14:41

In our DNS, all of the DCs are listed in the DNS as ourdomain.com. I believe this is expected behavior. If you are worried about how logins are being handled, then you are looking at the wrong DNS entries. For a description of how clients find their site's DCs, take a look at the following article.


If the issue is the DFS location of a local share, you might take a look at this thread: http://www.activedir.org/ListArchives/tabid/55/forumid/1/postid/35786/view/topic/Default.aspx

| improve this answer | |
  • Yes, I've read that article. In essence, the branch computers should be choosing a local Domain Controller (i.e., on the same subnet and/or site). Does that not apply to the DNS resolution for the FQDN itself? – pepoluan May 23 '12 at 14:36
  • No. DNS resolution is its own beast. But now you may be talking about DFS resolution. – uSlackr May 23 '12 at 15:14
  • I don't get it... you mean the clients resolves \\fqdn differently from ping fqdn? – pepoluan May 25 '12 at 3:09

As uSlacker mentioned, this may not actually adversely affect operation of Windows clients and certain functions such as ldap communication. This is due to how the internal Windows dc locator process functions, which among other things, prioritizes selected domain controllers by site.

A straight dns lookup at the command prompt is just that - a DNS lookup. If a domain controller has registered it's A record in the domain zone, it may be returned as a response to a DNS query. You may want to inspect your DNS zone and confirm which domain controllers have registered an A record.

If a packet capture reveals that branch computers are using a domain controller in another site, it may be due to it is common to configure domain controllers in spoke sites (branch offices) to use DNS mnemonics, that instructs a domain controller which DNS records to avoid registering. In large directories, it is actually quite common for spoke domain controllers to not register an A record in their DNS zone. If the branch office location also does not have a site associated with it's subnet, that may explain an affinity for the main site domain controllers.

More information:

How to optimize the location of a domain controller that resides outside of a client's site

| improve this answer | |
  • Well, the branches' subnets are all properly assigned to their own sites. But thanks for the article; I can glimpse some vague clues now... – pepoluan May 23 '12 at 14:39
  • 2
    A quick way to determine what DC a client has authenticated against is to run the following from a command prompt: echo %logonserver% – joeqwerty May 23 '12 at 15:45
  • Glad to help... – joeqwerty May 25 '12 at 3:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.