Active Directory’s Reliance on DNS, and using an ISP’s DNS address

—
Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services
Active Directory, Exchange and Windows Infrastructure Engineer

Compiled 5/2007, Edited 9/18/09 to add info regarding desktops, Updated 6/14/2010
—

Prelude

You wake up and get ready for work. You sit down and have a bowl of cereal. You crack open a full gallon of milk. Now there’s a little less in the gallon, but you know you have plenty of milk for the next couple of days. You walk out of your house and drive off to work. Upon returning, you find the milk is missing. You know you had some milk left over when you left for work in morning. You walk out front and see your neighbor just happens to be outside. You walk over to him and ask him, “Do you know what happen to my milk?” He just stares at you not knowing what you’re talking about.

Can your neighbor, an outside entitiy to your internal household, respond to that? The same thing is occuring when you use an outside DNS server in your NIC properties (whether on the DC, member servers and/or client machines). If the machines are set to use an outside DNS address, then your machines are literally asking an outside entity, “What’s the IP address of my domain controller?” The outside DNS servers do NOT have that answer.

Using an ISP’s DNS

What will happen if you use an ISP’s DNS addess, or a router as a DNS address on a DC or client machine, is the machine (whether a DC or client), will ask the ISP’s DNS, “What is my DC’s IP address? I need to know because I would like to send a logon request.” The ISP’s DNS doesn’t have that answer. Their DNS servers do not host the your internal AD zone name therefore, they have no information about your internal AD network. It’s like me asking that guy down the street that I’ve never met, “Hey you, where did all the beer or milk go in my refridgerator?” He won’t have that answer either. 🙂

I’ve read and responded to numerous newsgroup and forums posts requesting assistance, as well as new customers I’ve been called upon to fix issues, with such complaints as taking a long time to login, can’t access printers or mapped drives, Outlook fails to find the Exchange servers, among other issues.

I’ve also seen other errors such as GPOs not working, can’t find the domain, RPC issues, Exchange profusely failing and its services not wanting to start, users complaining they can’t get their emails, etc, when the ISP’s DNS servers are listed on a client, DCs and/or member servers, or with DCs.

After a short investigation, I’ve come to find that the domain controllers network properties have included either an ISP’s DNS address, the ISP’s router’s IP address, or some other external DNS server as an IP address in the NIC’s properties. I’ve also observerd that using a non-internal DNS addrsses were also found on internal company desktops and laptops, whether the IP conifiguration was set by a static entry, or from DHCP (DHCP Option 006).

This type of conifiguration can and will lead to numerous issues with a Active Directory, from authentication issues, replication issues, to much more.

I hope this explanation provides a greater understanding on how it all works and exemplifies to not ONLY use the internal DNS server for all internal machines, but as well as in the VPN’s DHCP service for VPN clients. Keep in mind, a client machine plugged in at home, using an aircard, or say sitting at Starbucks, will probably be configured with an ISP’s anyway if outside the network. That is fine. If using a VPN connected to the office, the VPN client will use that DNS to find the VPN server for your network. But once the VPN authenticates and connects, the VPN will be configured with your company’s internal DNS servers on its interface, and because the VPN interface by default is the first in the binding order, therfore the first interface it will use, will be able to logon to the domain and authenticate to the domain in order to access internal resources, which is what you want it to do.

The Usual Suspects That Can Cause Issues with AD Communications, long logon times, etc

Here is a summarized list of possible causes, but NOT limited to:

Single label name Active Directory DNS domain name (extremely problematic).
SRV records missing. This can be due to DNS or network interface card (NIC) mis-configuration.
Disjointed namespace.- AD domain name doesn’t match the Primary DNS Suffix and/or the zone name.
Using an ISP’s or some other DNS server that is not hosting the AD zone or that doesn’t have a reference to it, in IP properties of the DCs and clients.
DHCP Client service disabled on the DCs (a required service even if statically configured)
DCs are possibly multihomed. A multihomed DC has more than one unteamed NIC, more than one IP and/or RRAS installed such as for VPN purposes, which makes it problematic if not configured properly (more info on this below).
A third party firewall or security application is installed blocking traffic.
Antivirus software blocking functionality
Antispyware blocking functionality

AD & DNS Configuration

When I’ve visited a customer site to fix issues and noticing the DNS entries are incorrect on the DC(s), upon interviewing the parties involved that had configured the machines, simply stated they were not aware of this requirement.

Usually it simply comes down to a simple misunderstanding of AD and how DNS works, as well as the Client Side Resolver Service. Some ISPs will tell their customers that they need to use the router as a DNS address, or that they need to use their DNS servers out on the internet, or they warn them that they will not resolve internet names. The ISP customer service reps are not well versed with how AD and DNS works, and frankly provide misguided advise.

Keep in mind, if a DC goes down for whatever reason, or simply not be available because the clients can’t “find” the DC,, so will your Exchange server, AD domain functions, mapped drive access, printer access, etc. If the DC actually went down, such as hardware failure, this is a worst case scenario and wouldn’t matter to config your machines with the ISP’s DNS. If you need, you can configure your own workstation to the ISP’s during such a crisis in case you need outside communication to research the problem, but you must change it back to your internal DNS once you’re done researching the issue and/or you’ve fixed the problem.

FYI about AD, DNS, authentication, finding the domain, GPOs, RPC issues,ISP’s DNS servers, etc

Active Directory stores it’s resources and service locations in DNS in the form of SRV records (those folder names with the underscores in them). These records are used for a multitude of things, such as finding the domain when a client logons, domain replication from one DC to another, authentication, and more.

If the ISP’s DNS is configured in the any of the internal AD member machines’ IP properties, (including all client machines and DCs), the machines will be asking the ISP’s DNS ‘where is the domain controller for my domain?”, whenever it needs to perform a function, (such as a logon request, replication request, querying and applying GPOs, etc). Unfortunately, the ISP’s DNS does not have that info and they reply with an “I dunno know”, and things just fail. Unfortunately, the ISP’s DNS doesn’t have information or records about your internal private AD domain, and they shouldn’t have that sort of information.

Therefore, with an AD infrastructure, all domain members (DCs, clients and servers), must only use the internal DNS server(s).

If for instance a user wanted to log on, part of the logon process involves the machine to find where the DCs are. The machine will ask DNS, “Where is my domain controller?” If the machine is properly set to use only the internal DNS servers, it will be able to respond with an answer, thus the user can logon.

If the machine asks the 4.2.2.2 DNS server, “Where is my domain controller?”, will it have that answer? No, unfortunately not.

Also, it is highly recommended to not use your firewall or router as a DNS or DHCP server. If you are using your NT4 as a DNS server in your AD domain, change it over to Win2003 DNS. Same with DHCP. NT4 DNS cannot support AD’s SRV requirements and dynamic updates. Windows DHCP service supports additional features for DNS Dynamic updates, as well as other features, that a router or firewall’s DHCP server does not support.

Do not configure the DNS client settings on the domain controllers to point to your Internet Service Provider’s (ISP’s) DNS servers or any other DNS other than the DNS hosting the AD zone, otherwise…
http://smtp25.blogspot.com/2007/05/do-not-configure-dns-client-settings-on_818.html

Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain (whether it was upgraded or not, this is full of useful information relating to AD and DNS, among other info):
http://support.microsoft.com/?id=555040

The DNS Client Side Resolver Service

Another question that has come up is, “Why can’t I use the ISP’s address as the second entry?” This will cause problems as well, due to the way the client side resolver works, which is the resolver service that runs on all machines – DC or workstation – that queries DNS and what to do with the answer. Yes, the domain controller, too, after all the domain controlleris also a DNS client, because it will query DNS to “find” itself.

The Client Side Resolver will query the first DNS server listed in the NIC’s properties. If that server doesn’t respond, it will remove it from the ‘eligible resolver list” for 15 “minutes and go on to the next one in the list. So say if the client happens to try to authenticate to AD in order to access a printer, and it’s stuck on the ISP’s, it will fail to connect until the 15 minute time out period expires and the list resets.

To summarize, if there are multiple DNS entries on a machine (whether a DC, member server or client), it will ask the first entry first. If it doesn’t have the answer, it will go to the second entry after a time out period, or TTL, which can last 15 seconds or more as it keeps trying the first one, at which then it REMOVES the first entry from the eligible resolvers list, and won’t go back to it for another 15 minutes at which time the list is reset back to the original order. This can cause issues within AD when accessing a resource such as a printer, folder, getting GPOs to function, etc. Now if the ISP’s is the first one, obviously it will be knocked out when a client is trying to login. This can be noticed by a really really logon time period the client will experience before it goes to the second one, your internal DNS. Therefore, the first one is knocked out for 15 minutes. Then let’s say the client decides to go to an internet site. It will be querying the internal DNS at this point. As long as the internal DNS is configured with forwarders to an outside DNS, or using it’s Root Hints, it will resolve both internal and external internet addresses.

In summary, based on the way the client side resolver service algorithm works, you simply can’t mix an ISP or some other DNS server that doesn’t host the AD zone name or have some sort of reference to it, whether using a conditional forwarder, stub, secondary or general forwarder, or expect problems. Read the following for more detail and understanding of the client side resolver service algorithm.

DNS Client side resolver service
http://technet.microsoft.com/en-us/library/cc779517.aspx

The DNS Client Service Does Not Revert to Using the First Server in the List in Windows XP
http://support.microsoft.com/kb/320760

Then if I don’t use the ISP’s DNS address in my machines, how will it resolve internet names?

For Internet resolution, the Root Hints will be used by default, unless a root zone exists. The root zone actually looks like a period that you normally type at the end of a sentence, such as a dot “.” zone. If a root zone exists, delete it, and restart the DNS server service.

Therefore, the recommended “best practice” to insure full AD and client functionality is to point all machines ONLY to the internal server(s), and configure a forwarder to your ISP’s DNS server properties (rt-click DNS servername, properties, Forwarders tab). This way all machines query your DNS and if it doesn’t have the answer, it asks outside. If the forwarding option is grayed out, delete the Root zone (that dot zone). If not sure how to perform these two tasks, please follow one of the articles listed below, depending on your operating system, for step by step.

300202 – HOW TO Configure DNS for Internet Access in Windows Server 2000 (Configure Forwarding) :
http://support.microsoft.com/?id=300202

323380 – HOW TO Configure DNS for Internet Access in Windows Server 2003 (Configure Forwarding) :
http://support.microsoft.com/?id=323380

How to Configure Conditional Forwarders in Windows Server 2008
http://msmvps.com/blogs/ad/archive/2008/09/05/how-to-configure-conditional-forwarders-in-windows-server-2008.aspx

Configure a DNS Server to Use Forwarders – Windows 2008 and 2008 R2
http://technet.microsoft.com/en-us/library/cc754941.aspx

DNS Conditional Forwarding in Windows Server 2003
http://www.windowsnetworking.com/articles_tutorials/DNS_Conditional_Forwarding_in_Windows_Server_2003.html

825036 – Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003
http://support.microsoft.com/?id=825036

Multihomed Domain Controllers

Another issue I’ve encountered is when a non-SBS domain controller has been configured with mutiple NICs, IP addresses, and/or RRAS. This is another problematic configuration that is dubbed as a “multihomed domain controller.” Multihomed DCs are extremely problematic if not configured correctly, however to configure one correctly involves a multitude of steps including registry changes to alter DNS registration. However, this blog is not intended to discuss multihomed DCs, rather to discuss using an ISP’s DNS address in your network. For more information on multihomed DCs, please read the following link to my blog on it, and how to configure it.

Multihomed DCs with DNS, RRAS, and/or PPPoE adapters:
http://blogs.dirteam.com/blogs/acefekay/archive/2009/08/03/multihomed-dcs-with-dns-rras-and-or-pppoe-adapters.aspx

Summary

If you have your ISP’s DNS addresses in your IP configuration (all DCs, member servers and clients), they need to be REMOVED and ONLY use the internal DNS server(s). This will cause numerous problems with AD.

Active Directory’s Reliance on DNS, and using an ISP’s DNS address

Active Directory’s Reliance on DNS, and using an ISP’s DNS address

Prelude

Using an ISP’s DNS

The Usual Suspects That Can Cause Issues with AD Communications, long logon times, etc

AD & DNS Configuration

FYI about AD, DNS, authentication, finding the domain, GPOs, RPC issues,ISP’s DNS servers, etc

The DNS Client Side Resolver Service

Then if I don’t use the ISP’s DNS address in my machines, how will it resolve internet names?

Multihomed Domain Controllers

Summary

Related Links

Leave a Reply Cancel reply