Multihomed DCs with DNS, RRAS, and/or PPPoE adapters

Multihomed DCs with DNS, RRAS, and/or PPPoE adapters


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

Published 4/2009
First compiled January, 2003
Updated July, 2006
Updated 5/2010 with a new Step #10
Updated 10/14/2010 adding a new section about AD communications across a NAT
Updated 1/22/2011 – Added about NIC teaming NOT supported by Microsoft. Better to disable the additional NIC then use teaming.

 

What is a Multihomed DC?

A Multihomed DC is a domain controller with more than one NIC and/or IP address, and/or RRAS installed on it (for VPN, routing, dialup, etc), or with a PPPoE adapter from your ISP’s ADSL line.

Multihomed DCs wiill cause numerous issues. The only exception to the rule are SBS servers, but that is a completely different topic which I will not address in this blog, but I can add that even the SBS gurus recommend to single-home it.

It’s highly recommended to single-home all DCs and use a non-DC for multihoming purposes. If it’s the internet gateway, such as using the DC as a NAT device, not only will the multihomed DC cause AD problems, but you’re also exposing the DC directly on the internet. To overcome both of these issues, I recommend disabling the outer NIC and purchasing an inexpensive cable/DSL firewall/router or other type of firewall/NAT device for this purpose. My preference is a Cisco ASA device. There are also less expensive options, such as a Linksys wireless N router for less than USD $150, and there are less expensive models under it. If the hardware device is compromised by an internet attacker remotely, it can’t further compromise the rest of the internal network, nor your DC.

If you have a PPPoE adapter installed (such as the WinPoet software from Verizon for ADSL lines), it will cause the same problems, for after all, they are additional interfaces.

 

Internet Connection Services (ICS) on a DC

If attempting to use Internet Connection Serivices (ICS) on a DC, this further complicates matters with DC functionality, because ICS has it’s own built-in DNS and DHCP service that is non-configurable, and cannot be fixed with the following steps outlined in this article. I suggest disabling it.

 

AD’s reliance on DNS

To explain why multhoming a DC causes problems will require a little background on AD and DNS.

You can’t use your ISP’s DNS in your DC and workstation NIC properties

Let’s put this into layman’s terms: Let’s say the NFL SUperbowl is tomorrow, and I invited a few friends over. I went out and bought two cases of beer for the game. I put them into the refridgerator. So I know those cases are in the rerfidgerator before I went to bed. I wake up to find half the case is gone. No one else was in the house last night. I walk out front and see my neighbor washing his car. I yell over to him, “Hey, do you know where my beer went that I had in my refridgerator?” He responds that he has no idea. Nor that I would expect him to know. THis is the same as if I used Comcast’s or some other ISP’s DNS address in my DC or my workstations. When the workstation or DC needs AD communications and functionality, it will be asking the Comast DNS servers, “Hey, what is the IP address of my domain controller?” Will it have that answer? No, it won’t.

To understand the specifics behind AD’s reliance on DNS, please read the following article:

Active Directory’s Reliance on DNS, and using an ISP’s DNS address:
http://msmvps.com/blogs/acefekay/archive/2009/08/17/ad-and-its-reliance-on-dns.aspx

Also, you can’t mix an external DNS address with your internal address. THis is due to the way the client side resolver service works. You need to only use your own internal DNS address. For efficient internet name resolution, you can configure a Forwarder to your ISP’s DNS server. That’s done in DNS properties, Forwarders tab. To understand this process, please read the following article:

DNS, WINS NetBIOS & the Client Side Resolver, Browser Service, Disabling NetBIOS, Direct Hosted SMB (DirectSMB), If One DC is Down Does a Client logon to Another DC, and DNS Forwarders Algorithm if you have multiple forwarders.
http://msmvps.com/blogs/acefekay/archive/2009/11/29/dns-wins-netbios-amp-the-client-side-resolver-browser-service-disabling-netbios-direct-hosted-smb-directsmb-if-one-dc-is-down-does-a-client-logon-to-another-dc-and-dns-forwarders-algorithm.aspx

Bascially, AD required DNS

Basically, AD requires DNS. DNS stores AD’s resource and service locations in the form of SRV records, hence how everything that is part of the domain will find resources in the domain. 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 (or your router as a DNS server) DNS doesn’t have information or records about your internal private AD domain, and they shouldn’t have that sort of information.

Also, AD registers certain records in DNS in the form of SRV records that signify AD’s resource and service locations. When there are multiple NICs, each NIC registers. IF a client, or another DC queries DNS for this DC, it may get the wrong record. One factor controlling this is Round Robin. If a DC or client on another subnet that the DC is not configured on queries for it, Round Robin will kick in offering one or the other. If the wrong one gets offered, it may not have a route to it. On the other hand, Subnetmask Priortization will ensure a querying client will get an IP that corresponds to the subnet it’s on, which will work.

AD’s reliance on DNS MUST BE FULLY understood to understand why multihoming causes problems. Once again, to understand the specifics behind AD’s reliance on DNS, please read the following article:

Active Directory’s Reliance on DNS, and using an ISP’s DNS address:
http://msmvps.com/blogs/acefekay/archive/2009/08/17/ad-and-its-reliance-on-dns.aspx

After reading the above article. you should now understand and realize that if you are using your ISP’s DNS addresses, some other external DNS address that doesn’t host the internal AD zone, or using your router as a DNS address in your IP configuration (DCs or workstations), they must be removed. If these external DNS addresses are used, it’s guaranteed to cause additional problems. If not sure what I mean that you can’t use a DNS server other than your internal DNS servers, please re-read the above article.

 

 Errors caused by using a DNS address that does not host the AD zone

I usually see errors (GPOs not working, can’t find the domain, RPC issues, replication taking a nose dive, dcdiag and replmon errors, etc), when the ISP’s or some other non-internal DNS servers are listed on a client, DCs and/or member servers, or with multihomed DCs. If you have an ISP’s (or some other outside DNS server or even using your router as a DNS server) 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). Otherwise, expect problems. Surprisingly I’ve heard of some customers say, “I’ve been using it for years this way and have never had problems.” Consider yourself lucky.

 

If you have multiple IPs on one NIC, you can control which gets registered into DNS

You can control the default DNS registration process of registering multiple IPs that have been configured on a single NIC. If this is the scenario, then you won’t need to follow the procedure later in this blog. However, if you have multiple NICs, this does not work.

“All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2”
http://support.microsoft.com/kb/975808/EN-US

 

To insure everything works, stick with one NIC

Since this DC is multi-homed, it requires additional configuration to prevent the public interface addresses from being registered in DNS. This creates a problem for internal clients locating AD to authenticate and find other services and resources such as the Global Catalog, file sharing  and the SYSVOL DFS share and can cause GPO errors with Userenv 1000 events to be logged, authenticating to shares and printers, logging on takes forever, among numerous other issues.

But if you like, there are some registry changes to eliminate the registration of the external NIC or simply use the internal networking routing to allow access.

Another problem is the DC now becomes part of two Sites. This is another issue that can be problematic.

But believe me, it’s much easier to just get a separate NAT device or multihome a non-DC then having to alter the DC. If the both NICs are internal, I would suggest to pick a subnet, team the NICs and allow your internal routers handle the traffic between subnets – Good luck!

 

NIC Teaming on a Domain Controller – Not recommended nor Supported by Microsoft!

Although teaming sounds like a good idea to eliminate a multihomed scenario for such cases where both NICs are on the same segment and you have the NIC vendor software installed that offers teaming, but I must point out that teaming NICs on DCs, or any other servers, is not recommended, nor is it supported by Microsoft:

Teamed network cards for domain controllers? (Thread Answered by a great write-up by Jared Crandall, former Microsoft Support Engineer)
http://social.technet.microsoft.com/Forums/en/winserverDS/thread/f5dea401-5a3b-4ddb-8bb8-8d2b2e2db55b

Using teaming adapters with network load balancing may cause network problems
http://support.microsoft.com/kb/278431

however did you know Nic teaming NICs on a DC, or any other Windows box is not a good idea,
http://tinyurl.com/4pbpnfp

 

 

The following are the manual steps to configure a Multihomed DC

1. Insure that all the NICS only point to your internal DNS server(s) only and none others, such as your ISP’s DNS servers’ IP addresses.
 

2. In Network & Dialup properties, Advanced Menu item, Advanced Settings, move the internal NIC (the network that AD is on) to the top of the binding order (top of the list).
 

3. Disable the ability for the outer NIC to register. The procedure, as mentioned, involves identifying the outer NIC’s GUID number. The following link will show you how:

246804 – How to Enable-Disable Windows 2000 Dynamic DNS Registrations (per NIC too):
http://support.microsoft.com/?id=246804
 

4. Disable NetBIOS on the outside NIC. That is performed by choosing to disable NetBIOS in IP Properties, Advanced, and you will find that under the “WINS” tab.
 
You may want to look at step #3 in the following article to show you how to disable NetBIOS on the RRAS interfaces if this is a RRAS server.

Chapter 11 – NetBIOS over TCP/IP
http://technet.microsoft.com/en-us/library/bb727013.aspx

Or enable/disable NetBIOS on an interface in the registry:

To do it in the registry  but you will need to identify the GUID of that interface – (this may not apply to PPP interfaces)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NetBT\Parameters\Interfaces, find the GUID(s) with NetbiosOptions set to 0 and set them to 2.

Using WMIC:

First, get the list of interfaces:
wmic nicconfig get caption,index,TcpipNetbiosOptions

Then use the “index number” in the next command:
wmic nicconfig where index=1 call SetTcpipNetbios 2

SetTcpopNetbios options are:

0 – Use NetBIOS setting from the DHCP server
1 – Enable NetBIOS over TCP/IP
2 – Disable NetBIOS over TCP/IP

More info on the wmic commands and the registry entries can be found in this forum thread link:

Thread – Configuring NetBIOS over TCP/IP
http://social.technet.microsoft.com/Forums/en-US/winservercore/thread/d18bd172-e1a0-4a61-ba52-0952a1e3cabc/

Configure TCP/IP to use WINS
http://technet.microsoft.com/en-us/library/cc757386(WS.10).aspx  

Note:
A standard Windows service, called the “Browser service”, provides the list of machines, workgroup and domain names that you see in “My Network Places” (or the legacy term “Network Neighborhood”). The Browser service relies on the NetBIOS service. One major requirement of NetBIOS service is a machine can only have one name to one IP address. It’s sort of a fingerprint. You can’t have two brothers named Darrell. A multihomed machine will cause duplicate name errors on itself because Windows sees itself with the same name in the Browse List (My Network Places), but with different IPs. You can only have one, hence the error generated.
 

5. Disable the “File and Print Service” and disable the “MS Client Service” on the outer NIC. That is done in NIC properties by unchecking the respective service under the general properties page. If you need these services on the outside NIC (which is unlikely), which allow other machines to connect to your machine for accessing resource on your machine (shared folders, printers, etc.), then you will probably need to keep them enabled.

6. Uncheck “Register this connection” under IP properties, Advanced settings, “DNS” tab. 

7. Delete the outer NIC IP address, disable Netlogon registration, and manually create the required records

      a. In DNS under the zone name, (your DNS domain name), delete the outer NIC’s IP references for the “LdapIpAddress”. 

      b. If this is a GC, you will need to delete the GC IP record as well (the “GcIpAddress”). To do that, in the DNS console, under the zone name, you will see the _msdcs folder. Under the _msdcs folder, you will see the _gc folder. To the right, you will see the IP address referencing the GC address. That is called the GcIpAddress. Delete the IP addresses referencing the outer NIC.

            1. To stop these two records from registering that information, use the steps provided in the links below:

                Private Network Interfaces on a Domain Controller Are Registered in DNS
                http://support.microsoft.com/?id=295328 

             2.. The one section of the article that disables these records is done with this registry entry:

                   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
                   (Create this Multi-String Value under it):
                    Registry value: DnsAvoidRegisterRecords
                    Data type: REG_MULTI_SZ
                    Values: LdapIpAddress
                                  GcIpAddress

                     The following link provides more information on the LdapIpAddress and GcIpAddress, as well as other Netlogon Service records:

                      Restrict the DNS SRV resource records updated by the Netlogon service[includingGC]:
                      http://technet.microsoft.com/en-us/library/cc778029(WS.10).aspx
  

                3. Then you will need to manually create GcIpAddress and IpAddress records in DNS with the IP addresses that you need for the DC. To create the LdapIpAddress, manually create a new host under the domain, but leave the “hostname” field blank, and provide the internal IP of the DC, which results in a record that  looks like:
(same as parent) A 192.168.5.200              (192.168.5.200 is used for this example)

                 4. You need to also manually create the GcIpAddress as well, if this is a GC. That would be under the _msdcs._gc SRV record under the zone. It is created in the same fashion as the LdapIpAddress mentioned above.
  

8. In the DNS console, right click the server name, choose properties, then under the “Interfaces” tab, force it only to listen to the internal NIC’s IP address, and not the IP address of the outer NIC.

9. Since this is also a DNS server, the IPs from all NICs will register, even if you tell it not to in the NIC properties. See this to show you how to stop that behavior (this procedure is for Windows 2000, but will also work for Windows 2003):

275554 – The Host’s A Record Is Registered in DNS After You Choose Not to Register the Connection’s Address:
http://support.microsoft.com/?id=275554  
 

10. Disable the round robin functionality on the DNS server. To do so: (This step added 5/2010)
                    1. Click Start, click Settings, click Administrative Tools, and then click DNS.
                    2. Open the properties for the DNS server’s name.

11. If you haven’t done so, configure a forwarder. You can use 4.2.2.2 and 4.2.2.3, if not sure which DNS to forward to until you’ve got the DNS address of your ISP. How to set a forwarder? Good question. Depending on your operating system, choose one of the following articles, depending on your operating system.

 
300202 – HOW TO: Configure DNS for Internet Access in Windows 2000
http://support.microsoft.com/?id=300202 
 
323380 – HOW TO: Configure DNS for Internet Access in Windows Server 2003 (How to configure a forwarder):
http://support.microsoft.com/d/id?=323380 

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

Active Directory and NAT

I thought to touch base on this overlooked fact about AD communication through a NAT.

If a planned resources is to be provided in the AD infrastructure that uses AD authentication (Kerberos) that must traverse a NAT, it basically won’t work. This is due to secure RPC communications and NAT not being able to translate the traffic due to the encryption. If you really need to make it work, there are solutions to work around it, such as a Direct VPN between the services across the NAT devices, or additional NICs directly connecting them. More on it in this link, and Microsoft’s take and solution on it:

Description of support boundaries for Active Directory over NAT
http://support.microsoft.com/default.aspx?scid=kb;en-us;978772&sd=rss&spid=12925

Active Directory communication fails on multihomed domain controllers
http://support.microsoft.com/kb/272294 

 

Source IP address selection on a Multi-Homed Windows Computer

There is often confusion about how a computer chooses which adapter to use when sending traffic. This blog describes the process by which a network adapter is chosen for an outbound connection on a multiple-homed computer, and how a local source IP address is chosen for that connection.

Source IP address selection on a Multi-Homed Windows Computer
http://blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx

 

For multihomed non-DCs that have DNS installed: 

In instances where you are running a separate DNS server internally to host public records and the server is configured with a private IP and different internal name than your hostname server records, you will need to disable registration due to the NS and SOA records that get created and manually create the records under the Nameserver tab, and change the SOA record under the General tab. To disable registration:

To disable registration on Windows 2003 SP2 and 2008 and newer:

Tcpip\Parameters
The following registry entries are located under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

RegistrationEnabled    (This DWORD registry entry is a global setting that affects all interfaces on a machine.)
Value = 0   (Disabled = 0, Enabled =1)

More info on these registry settings can be found here:

 Windows 2003 & 2008 DNS Registry Settings:
 http://technet.microsoft.com/en-us/library/dd197418(WS.10).aspx

 

Related Links

More links to read up and understand what is going on with multihoming and the implications it causes.

Multihoming a Windows Server, by Gunner
http://networkadminkb.com/Shared%20Documents/Multihoming%20a%20Windows%20Server.aspx

292822 – Name Resolution and Connectivity Issues on Windows 2000 Domain Controller with Routing and Remote Access and DNS Insta {DNS and RRAS and unwanted IPs registering]:
http://support.microsoft.com/?id=292822 

Active Directory communication fails on multihomed domain controllers
http://support.microsoft.com/kb/272294 

246804 – How to enable or disable DNS updates in Windows 2000 and in Windows Server 2003
http://support.microsoft.com/?id=246804  

295328 – Private Network Interfaces on a Domain Controller Are Registered in DNS [also shows DnsAvoidRegisterRecords LdapIpAddress to avoid reg sameasparent private IP]:
http://support.microsoft.com/?id=295328  

306602 – How to Optimize the Location of a DC or GC That Resides Outside of a Client’s Site [Includes info LdapIpAddress and GcIpAddress information and the SRV mnemonic values]:
http://support.microsoft.com/kb/306602 

825036 – Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003 (including how-to configure a forwarder):
http://support.microsoft.com/kb/825036 

291382 – Frequently asked questions about Windows 2000 DNS and Windows Server 2003 DNS
http://support.microsoft.com/?id=291382 

296379 – How to Disable NetBIOS on an Incoming Remote Access Interface [Registry Entry]:
http://support.microsoft.com/?id=296379 

Rid Pool Errors and other multihomed DC errors, and how to configure a multihomed DC, Ace Fekay, 24 Feb 2006
http://www.ureader.com/message/3244572.aspx  

257623 257623 Domain Controller’s Domain Name System Suffix Does Not Match Domain Name
http://support.microsoft.com/?id=257623

Additonal Links added 5/21/2010:

157025 – Default Gateway Configuration for Multihomed Computers
http://support.microsoft.com/default.aspx?scid=kb;en-us;157025&Product=win2000

Default gateways
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/6c7c7ab2-cfdc-4dfe-8560-570d3859f5b1.mspx

Default Gateway Behavior for Windows TCP/IP
http://www.microsoft.com/technet/community/columns/cableguy/cg0903.mspx

159168 – Multiple Default Gateways Can Cause Connectivity Problems
http://support.microsoft.com/kb/159168/EN-US/

Name resolution and connectivity issues on a Routing and Remote Access
Server that also runs DNS or WINS
http://support.microsoft.com/kb/292822/en-us

272294 – Active Directory Communication Fails on Multihomed Domain
Controllers
http://support.microsoft.com/default.aspx?scid=kb;en-us;272294

191611 – Symptoms of Multihomed Browsers
http://support.microsoft.com/default.aspx?scid=kb;EN-US;191611

Microsoft Windows XP – Multihoming Considerations
http://www.microsoft.com/resources/documentation/windows/xp/all/reskit/en-us/prcc_tcp_qpzj.asp?

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


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:

  1. Single label name Active Directory DNS domain name (extremely problematic).
  2. SRV records missing. This can be due to DNS or network interface card (NIC) mis-configuration.
  3. Disjointed namespace.- AD domain name doesn’t match the Primary DNS Suffix and/or the zone name.
  4. 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.
  5. DHCP Client service disabled on the DCs (a required service even if statically configured)
  6. 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).
  7. A third party firewall or security application is installed blocking traffic.
  8. Antivirus software blocking functionality
  9. 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