Intro
Ace again. Time to re-hash why DNS is important, or actually, NEEDED for Active Directory, and Azure AD .
Consider this….
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 entity to your internal household, respond to that? The same thing is occurring 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 address, 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 refrigerator?” 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 observed that using a non-internal DNS addresses were also found on internal company desktops and laptops, whether the IP configuration was set by a static entry, or from DHCP (DHCP Option 006).
This type of configuration 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 air card, 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, therefore 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.
Related Links
291382 – Frequently asked questions about Windows 2000 DNS and Windows Server 2003 DNS
http://support.microsoft.com/?id=291382
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
Domain Controller’s Domain Name System Suffix Does Not Match Domain Name:
http://support.microsoft.com/?id=257623
Clients cannot dynamically register DNS records in a single-label forward lookup zone:
http://support.microsoft.com/?id=826743
300684 – Information About Configuring Windows 2000 for Domains with Single-Label DNS Names
http://support.microsoft.com/?id=300684
828263 – DNS query responses do not travel through a firewall in Windows Server 2003:
http://support.microsoft.com/?id=828263
============================================================
Summary
I hope this provided a good understanding of DNS!!!
Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services
![clip_image0023[2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image00232-1.jpg "clip_image0023[2]")
![clip_image0043[2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image00432-1.jpg "clip_image0043[2]")
![clip_image0063[2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image00632-1.jpg "clip_image0063[2]")
![clip_image0083[2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image00832-1.png "clip_image0083[2]")
![clip_image0103[2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image01032-1.jpg "clip_image0103[2]")
![clip_image0123[2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image01232-1.png "clip_image0123[2]")
![clip_image0143[2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image01432-1.jpg "clip_image0143[2]")
![clip_image0163[2]](https://blogs.msmvps.com/acefekay/files/2016/10/clip_image01632-1.png "clip_image0163[2]")
Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php
This posting is provided AS-IS with no warranties or guarantees and confers no rights.
