Solution 1:

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.

http://technet.microsoft.com/en-us/library/cc978016.aspx

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

Solution 2:

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
http://support.microsoft.com/kb/306602