What DNS Zone type should I use, a Stub, Conditional Forwarder, a Forwarder, or a Secondary Zone?? What’s the Difference??

By Ace Fekay
Originally Published 2012
Updated 3/20/2018

Intro

Ace again. DNS is a basic, yet important requirement that many still having problems wrapping their head around it.

Besides design, a huge part of DNS is understanding the differences between the zone types. Many have asked, when do I use a Stub zone, a Conditional Forwarder, or a Forwarder? Or better, what’s the difference?

I thought to put this simple comparison together compiled from past posts in the TechNet Forum.

Partner Organization DNS Resolution: What should I use, a Stub, Conditional Forwarder or Forwarder?

Secondary Zone

Secondary zones are read only copies “copied,” or “zone transferred” from a Master zone. This makes the zone data available locally (as read only, of course), instead of querying a DNS server across a WAN link. However, in many cases Secondaries are not used due to many limitations and security concerns, such as exposing all DNS zone data that a partner may not want to divulge.

In addition, Secondaries can’t be AD integrated, and the zone data is stored in a text file. So you would have to manually create a copy on all of your DNS servers.

Stub Zone

Organizations own their own AD zones. When business partners need to resolve data at a partner’s organization, there are a few options to support this requirement. Years ago, prior to Stub or Conditional Forwarders, there weren’t many options to handle this other than to use Secondary Zones and keep copies of each others zones via zone transfers.  While the solution worked well in regards to name resolution, it was not the best security-wise, due to trust level between partners, because zone data is fully exposed at the partner. This became a security concern because the partner is able to see all of their business partner’s records. When the zone was transferred to partners, who knows what they were doing with the information. If the information was made public, attackers would have a field day with all of the IPs for the networked devices.

When stub zones were made available, it became a solution to overcome this security issue. What is also beneficial about Stubs, is you can AD integrate them instead of manually creating a Stub on each individual DC. This way the zone will be available domain or forest-wide, depending on replication scope.

However, some may say due to the fact that the SOA records are included in the zone file, it may be a concern that the SOA and NS data is exposed. In such high security concerns, the better solution would be to use a Conditional forwarder.

Conditional Forwarder

This option is heavily used, and many look at them as the best regarding security concerns with zone data exposure, because no data is exposed. This option has worked very well in many environments.

With Conditional Forwarders, no information is being transerred and shared. The only thing you would need to know is one or more of your business partner’s DNS server IPs to configure it, and they don’t have to be the SOA, rather any DNS server that hosts the zone or that has a reference to the zone.

However, it does require open communication and let each other know when their DNS server IPs may change, because you must manually set them.

Windows 2003 introduced Conditional Forwarders, but it did not have the option to make it AD Integrated. If you have 10 DNS servers, you must create the Conditional Forwarder on each server manually. The AD integrated option was added to Windows 2008 or newer DNS servers, so you don’t have to manually create them on each DNS server. THis way the Conditional Forwarder will be available domain or forest-wide.

Parent-Child DNS Zone Delegation

Delegation can be used in a situation where a child domain host their own DNS zone.  Therefore in the forest root domain, you would create a delegation zone with the IPs of the DNS servers in the child domain.  This is normally performed when the child zone have their own administrators. It’s also useful they do not have access to “see” all of the forest root DNS records.

Summary

I hope this helps! If you have any questions, and I’m sure you do, please feel free to reach out to me.

Major revision – Published 3/20/2018

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2012|R2, 2008|R2, Exchange 2013|2010EA|2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Mobility

As many know, I work with Active Directory, Exchange server, and Office 365 engineer/architect, and an MVP in Active Directory and Identity Management, and I’m an MCT as well. I try to strive to perform my job with the best of my ability and efficiency, even when presented with a challenge, and then help others with my findings in case a similar issue arises to help ease their jobs. Share the knowledge, is what I’ve always learned.

I’ve found there are many qualified and very informative websites that provide how-to blogs, and I’m glad they exists and give due credit to the pros that put them together. In some cases when I must research an issue, I just needed something or specific that I couldn’t find or had to piece together from more than one site, such as a simple one-liner or a simple multiline script to perform day to day stuff.

I hope you’ve found this blog post helpful, along with my future scripts blog posts, especially with AD, Exchange, and Office 365.

clip_image0023 clip_image0043 clip_image0063 clip_image0083 clip_image0103 clip_image0123 clip_image0143 clip_image0163

Complete List of Technical Blogs
https://blogs.msmvps.com/acefekay/

This posting is provided AS-IS with no warranties or guarantees and confers no rights.


 

Active Directory DNS Single Label Names

Intro

Hey everyone, Ace again. Let’s discuss this issue. I hardly see this issue any more, because it was a previously prevalent when Active Directory was introduced, since there were some confusion about AD domain naming, and many IT admins used NT4’s domain naming guidelines. Man of us are now familiar with AD’s naming convention, and have more than likely renamed or rebuilt their AD domains. However, there are still some installations with this issue. 

How did it happen? Many reasons, such as lack of research on AD’s DNS requirements, assumptions, or a simple typo when originally upgrading from NT4 or promoting your new AD domain. It doesn’t matter now, because you were brought here to find out what to do with it.

I hope you find this blog informative on this issue and what to do about it.

First, let’s discuss a little background on the necessary components at play…

FQDN

First, let’s discuss the FQDN. What is an FQDN? It stands for “Fully Qualified Domain Name.” It is multi-level, or hierarchal, such as:

domain.com
domain.net
domain.local
childdomainname.domain.local
etc

What is a Single Label DNS Domain name?
The name is reminiscent of the legacy style NT4 domain NetBIOS domain names, such as:

DOMAIN
CORP
COMPANYNAME
etc

Unfortunately, since this does not work with DNS, and Active Directory relies on DNS, therefore, it does not work with Active Directory. Stay with me. I’ll explain…

DNS

DNS is a hierarchal database. Some call it a “tree” with a root (the ‘com’ or ‘net’, etc, name), then the trunk (the ‘domain’ portion of it), and the branches (such as www, servername, etc). The Root domain name, such as com, edu, net, etc, is also known as the TLD (Tope Level Domain name).

Basically you can look at a DNS domain name as having multiple levels separated by periods. The minimal requirment for an FQDN domain name, such as microsoft.com, is two levels. Then of course are your resource names, such as www, servername, or even child domain names under it.

Notice with a single label name there is only one name for the domain, or one level? Don’t get this confused with the NetBIOS domain name, that we were familiar with in the NT4 days. AD supports the NetBIOS domain name as well, but only as a NetBIOS domain name. It’s one of the domain names chosen when a machine is promoted into a domain controller for a brand new domain in a brand new forest. NT4 wasn’t reliant nor did it use DNS for NT4 domains. However, AD is reliant, therefore it must follow DNS naming rules.

Unfortunately the old NT4 style names are not hierarchal because there is only one level.
 
Since AD requires and relies on DNS, and DNS is a hierarchal database, a single label name does not follow any sort of hierarchy. DNS fails with single label names. Windows 2008, Windows 2003, XP and Vista have problems resolving single label names because it does not follow the proper format for a DNS domain name, such as domain.com, etc.

Also, Windows 2000 SP4 and all newer machines have problems querying single label names. It’s explained below by Alan Woods. Because clients query DNS for AD resources (domain controller locations and other services), they may have difficulty finding resources.

How did it happen? As I said earlier, it doesn’t matter now, because you were brought here to find out what to do with it.

Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain (or any AD upgrade or installation):
http://support.microsoft.com/kb/555040

Single Label Name Explanation

Another variation of the Single Label Name explanation that I had provided in a response to a post in the DNS and/or AD newsgroups at one time:

The issue is the single label name. Locally at HQ, it’s using NetBIOS to join, however remotely, it’s relying on DNS. DNS queries do not work properly with single label names on Windows 2000 SP4 and all newer machines.

Period. Why? good question. It’s based on the fact DNS is hierarchal. Hierarchal meaning it must have multi levels, a minimum of two levels.

The TLD (top level domain) is the root name, such as the com, net, etc., names. The client side resolver service algorithm (which is governed by the DHCP Client service which must be running on all machines, static or not),
relies on that name for the basis to find the second level name (the name “domain” in domain.com, etc.). If the name is a single label name, it thinks THAT name is the TLD.

Therefore it then hits the Internet Root servers to find how owns and is authoritative for that TLD.Such as when looking up Microsoft.com. It queries for the COM portion, which the roots return the nameservers responsible for the COM servers, then it queries for the servers responsible for Microsoft.com zone.

If it’s a single label, the query ends there, and it won’t go further. However what is funny (sic) is that even though the single label name is being hosted locally in DNS, it will NOT query locally first, because it believes it is a TLD, therefore goes through the normal resolution (recursion and devolution) process, which causes excessive query traffic to the internet Root servers.

How to fix it? Good question. Glad you’ve asked.

  1. The preferred “fix” (in a one line summary), is to install a fresh new domain properly named and use ADMT to migrate user, group and computer accounts into the new domain from the current domain.
  2. An alternative is to perform a domain rename, (difficulty depends on the operating system and which version of Exchange is installed).
  3. As a temporary resort, you can use the patch or band aid registry fix to force resolution and registration that is mentioned in the following link. This must be applied to every machine. Unfortunately it must be done on every machine in the domain, including the DCs, member servers, workstations and laptops.

Information About Configuring Windows 2000 for Domains with Single-Label DNS Names:
http://support.microsoft.com/?id=300684

Single Label Names and being a better Internet Neighbor

The following was posted by Microsoft’s Alan Woods in 2004:

Single label names, from Alan Woods, [MSFT], posted:

—– Original Message —–
From: “Alan Wood” [MSFT]
Newsgroups: microsoft.public.win2000.dns
Sent: Wednesday, January 07, 2004 1:25 PM
Subject: Re: Single label DNS

Hi Roger,

We really would prefer to use FQDN over Single labled. There are
alot of other issues that you can run into when using a Single labeled
domain name with other AD integrated products. Exchange would be a great
example. Also note that the DNR (DNS RESOLVER) was and is designed to
Devolve DNS requests to the LAST 2 names.

Example: Single Labeled domain .domainA
then, you add additional domains on the forest.
child1.domainA
Child2.child1.domainA

If a client in the domain Child2 wants to resolve a name in domainA
Example. Host.DomainA and uses the following to connect to a share
\\host then it is not going to resolve. WHY, because the resolver is
first going to query for first for Host.Child2.child1.domainA, then it
next try HOST.Child1.domainA at that point the Devolution process is
DONE. We only go to the LAST 2 Domain Names.

Also note that if you have a single labeled domain name it causes excess
DNS traffic on the ROOT HINTS servers and being all Good Internet Community
users we definitely do not want to do that.   NOTE that in Windows 2003,
you get a big Pop UP Error Message when trying to create a single labeled
name telling you DON’T DO IT.  It will still allow you to do it, but you
will still be required to make the registry changes, which is really not
fun.

Microsoft is seriously asking you to NOT do this.  We will support you but
it the end results could be limiting as an end results depending on the
services you are using.

Thank you,

Alan Wood[MSFT]

 

Related Articles – Even though they seem old, they STILL APPLY!!!

Common Mistakes When Upgrading a Windows 2000 Domain To a Windows 2003 Domain
http://support.microsoft.com/kb/555040

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

DNS and AD (Windows 2000 & 2003) FAQ:
http://support.microsoft.com/kb/291382

Naming conventions in Active Directory for computers, domains, sites, and OUs (Good article on DNS and other names)
http://support.microsoft.com/kb/909264

============================================================

Summary

I hope this helps!

Published 10/15/2016

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 clip_image0043 clip_image0063 clip_image0083 clip_image0103 clip_image0123 clip_image0143 clip_image0163

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.

Active Directory’s Reliance on DNS – Why not to use your ISP’s DNS

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:

  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

============================================================

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] clip_image0043[2] clip_image0063[2] clip_image0083[2] clip_image0103[2] clip_image0123[2] clip_image0143[2] 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.

What’s in an Active Directory DNS Name? Choosing the Same As Your Public Domain Name, a ".net" Version of Your Public Name, or ".local"

Original publication 5/2005
Updated 5/2010
Updated 10/15/2010 – Provided a link to my blog with a How-To deal with DNS and the name chosen, and Exchange 2007 & 2010 UC/SAN certificate considerations
Updated 10/21/2014 – Reflect changes by the certificate companies that no longer support .Local or any other non-public TLD.

IMPORTANT Note: UCC/SAN “.Local” and other private TLDs will no longer be supported

When you choose an internal name, it won’t matter, because you now must configure Exchange’s internet URLs to be identical as the external URLs to support your UCC/SAN certificate.

On the bright side, this will help with configuring clients internally and externally with the same name anyway. I’ve always configured my customer Exchange CAS URLs with the same name because of this reason.

More info:

Global changes in legislation regarding SAN SSL Certificates
http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/

 

Topics Covered:

  1. Preface: AD Design Considerations

  2. Scenario 1 – Same Name as your external name (Split-Zone)

  3. Scenario 2 – Sub domain name of the public domain name

  4. Scenario 3 – Choosing a TLD Variation of your Public Domain, such as the “.net” version of it

  5. Scenario 4 – Choosing a private TLD such as “.local”

  6. Exchange 2007 & 2010 UC/SAN certificate considerations

  7. Related Links

 

 

==================================================================

Preface: AD Design Considerations

Should I choose the same AD DNS domain name as my external public domain name (also called split-zone), choose a sub domain name of my public name, or should I choose a completely different name such as .local or .net?

I must say this is a classic question that has arisen on numerous occasions starting with the beginning days of AD.

Choosing a name for your internal AD DNS domain name can be based on a number of things, whether technical or political, or previous administrative experience. This has been highly discussed (not debated) in the past.

Whatever decision you make for an AD DNS FQDN domain name, just understand the ramifications. Actually I’m not going to try to get into any sort of debate, for there is really nothing to debate, nor help someone decide on what is ‘right’ or ‘wrong’ but rather just state the ramifications and implications of a name that you do decide on and how to get around them, no matter what the decision was based on.

 

Discussion on what name to choose

This discussion was between myself and Todd J. Heron, MVP, during the Summer of 2003.

Classic question:

“Which are the advantages of naming my domain with domain.com rather than domain.local? I have a domain.com registered for my Company that i use for my e-mail and Site Internet.”

There are different answers to this classic question and while these answers ultimately depend upon company preference, much of the direction will be based upon administrator experience.  The three basic scenarios outlined below are the most commonly given answers to the question, sometimes altogether and sometimes not.   Some company networks use a combination of these scenarios.  When explaining it to a relative beginner asking the question, many responses omit explanatory detail about all the scenarios, for fear of causing more confusion.

All three approaches will have to take both security and the end-user experience into perspective.  This perspective is colored by company size, budget, and experience of personnel running Active Directory and the network infrastructure (mostly with respect to DNS and VPN).  No one approach should be considered the best solution under all circumstances.  For any host name that you wish to have access from both your internal network and from the external Internet you need scenario 1, although it is the most DNS-intensive over time.   If you do not select this option and go with scenario 2, 3 or 4, consideration will have to be given to the fact that company end-users will need to be trained on using different names under different circumstances (based on where they are (at work, on the road or at home).

Since our discussion, I’ve expanded the Scenarios to include considerations when obtaining an Exchange 2007 or 2010 UC/SAN certificate. The certificate authorities will check all of the names for their registered owner. If you choose an internal name that just happens to be a real public domain name that you weren’t aware of, and owned by someone else, the certificate authorities will reject the certificate request. See Scenario 3 for more information.

 

==================================================================

Scenario 1 – Same Name as your external name (Split-Zone)

Choosing the same name internal/external (spilt-zone, or split-brain, whatever you want to call it) has the most administrative overhead. Why chosen?

Either because a misunderstanding of the pros/cons, political, or for ease of use.

Pros:

1. Their email address is their logon name. Easier to remember.

2.  Security.  Each DNS zone is authoritative for the zone of that name so therefore the external DNS zone and internal AD/DNS zone will NOT replicate with each other thereby prevent internal company records to be visible to the outside Internet.

3.  Short namespace.  Users don’t have to type in (or see) a long domain name when accessing company resources either internally or externally.  Names are “pretty”.

Cons:

1. Administrative overhead. If trying to get to your externally hosted website, it won’t resolve because a DNS server will not forward or resolve outside for what a zone that it hosts. You can overcome resolving the www.domain.com dilemma by using a delegation. Right-click your zone, new delegation, type in ‘www’ and provide the public SOAs for the name server(s). This way it will send the resolution request to the SOA and resolve that way. As for http://domain.com, that is difficult and would instruct all users to only use www.domain.com. This is because of the LdapIpAddress, the record that shows up as (same as parent), which EACH domain controller registers. So if you type http://domain.com, you will round robin between the DCs. To overcome that, on EACH DC, install IIS, then under the default website properties, redirect it to www.domain.com and let the delegation handle it.

Now if you were to be using SharePoint services, or something else that connects to the default website (no sub folders or virtual directories), then it becomes a problem. I know numerous installations setup with this and have operated fine for years.

2. Security.  Each DNS zone is authoritative for the zone of that name so therefore the external DNS zone and internal AD/DNS zone will NOT replicate with each other thereby prevent internal company records to be visible to the outside Internet.

3.  Any changes made to the public DNS zone (such as the addition or removal of an important IP host such as a web server, mail server, or VPN server) must added manually to the internal AD/DNS zone if internal users will be accessing these hosts from inside the network perimeter (a common circumstance).

4.  VPN resolution is problematic at best.  Company users accessing the network from the Internet will easily be able to reach IP hosts in the public DNS zone but will not easily reach internal company resources inside the network perimeter without special (and manual) workarounds such as maintaining hosts files on their machines (which must be manually updated as well every time there is a change to an important IP host in the public zone), entering internal host data on the public zone (such as for printers, SRV records for DCs, member server hosts, etc.), which exposes what internal hosts exist, or they must use special VPN software (usually expensive), such as Cisco, Netscreen, etc., which is more secure and reliable anyway.

For further reading on this scenario:
http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html
http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-split-horizon-common-server-names.html

With a Split-Zone, You may los the ability to access your website or other resources:

If you choose the same name, and you can’t access your internal website, or an external resource with the same name, you need to understand how to handle this with DNS. Read the following for specifics and a how-to.

Split Zone or no Split Zone – Can’t Access Internal Website with External Name
Published by AceFekay on Sep 4, 2009 at 12:11 AM  1278  0
http://msmvps.com/blogs/acefekay/archive/2009/09/04/split-zone-or-no-split-zone-can-t-access-internal-website-with-external-name.aspx

 

==================================================================

Scenario 2 – Sub domain name of the public domain name

Choosing a child name or delegated sub domain name of the public zone.

Examples:  Name such as ‘ad.domain.com’, or ‘corp.microsoft.com’. The AD DNS domain name namespace starts at corp.domain.com and has nothing to do with the domain.com zone.

Pros:

1. Minimal administrative overhead.

2. Forwarding will work.

3. The NetBIOS name will be ‘AD’ or ‘CORP’, depending on what you chose and what the users will see in the three-line legacy security logon box.

4.  Like Scenario 1, this method also isolates the internal company network but note this at the same time is also a disadvantage (see below).

5. Better than Scenario 1, internal company (Active Directory) clients can resolve external resources in the public DNS zone easily, once proper DNS name resolution mechanism such as forwarding, secondary zones, or delegation zones are set up.

6. Better than Scenario 1, DNS records for the public DNS zone do not need to be manually duplicated into the internal AD/DNS zone.

7. Better than Scenario 1, VPN clients accessing the internal company network from the Internet can easily navigate into the internal subdomain. It is very reliable as long as the VPN stays connected.

Cons:

1. Confusion on users if they decide on using their UPN.

2.  While there is security in an isolated subdomain, there is potential for exposure to outside attack.  The potential for exposure of internal company resources to the outside world, lies mainly in the fact that because when the public zone DNS servers receives a query for subdomain.externaldnsname.com, they will return the addresses of the internal DNS servers which will then provide answers to that query.

3. Longer DNS namespace.  This may not look appealing (or “pretty”) to the end-users.

4. Security. We are assuming that we can only access the internal servers thru a VPN and assuming they are in a private subnet, they won;’t be accessible. Also assuming to secure the VPN with an L2TP/IPSec solution and not just a quick PPTP connection. If this is all so, we can assume it is secure and not accessible from the outside world.

The scenario is the recommendation from the Windows Server 2003 Deployment Guide.  It states to the external registered name and take a sub zone from that as  the DNS name for the Forest Root Domain:
http://www.microsoft.com/resources/documentation/windowsserv/2003/all/deployguide/en-us/default.asp

 

==================================================================

Scenario 3 – Choosing a TLD Variation of your Public Domain, such as “.net”

Example: Public domain name is domain.com, and you choose “domain.net” as your public name.

This choice has been made by many companies.

Pros:

1. Easy to implement with minimal administrative overhead. Requires minimal action on administrators.

2. Prevents name space conflicts with external domain name. No one else owns it on the internet.

3. Forwarding works.

Cons

1. Domain name may look unprofessional. But this has nothing to do with anything on the public side (the internet).

2. VPN resolution difficult (like option 1) if DNS is not setup properly. That can be a sticky issue and depending on the VPN client will dictate whether it will work or not. I know one of the other MVPs (Dean Wells) created a little script to populate a user’s laptop or home PC’s hosts file with the necessary resources and would remove them once the VPN is dissolved.

3. Exchange HELO name must be altered in the SMTP properties (Exchange 2000 using MetaEdit, or SMTP properties in Exchange 2003), or in the Hub Transport properties (Exchange 2007) to accommodate anti-spam, SPF, and RBL software.

4. Obtaining a UC/SAN certificate for Exchange 2007 & 2010 may be a challenge if you haven’t registered the “.net” version of your public domain name. This is because the Certificate Authorities will check all names in the UC/SAN cert you are requesting, including Exchange’s internal FQDN in the certificate request. This is used by the AutoDiscover feature in Exchange 2007 and 2010 and needs to be in the certificate. Read more on it here:

Exchange 2007 & Exchange 2010 UC/SAN Certificate
http://msmvps.com/blogs/acefekay/archive/2009/08/23/exchange-2007-uc-san-certificate.aspx

==================================================================

Scenario 4 – Choosing a private TLD such as “.local”

Note: UCC/SAN “.Local” and other private TLDs will no longer be supported

When you choose an internal name, it won’t matter, because you can configure Exchange’s internet URLs to be identical as the external URLs. This will help with configuring clients internally and externally with the same name.

More info:

Global changes in legislation regarding SAN SSL Certificates
http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/

Choosing a private name

Choosing a different TLD: Choosing a private TLD, such as domain.local, domain.corp, domain.abc, etc. This option is easy for either beginners or the expert, because it’s the easiest to implement primarily because it prevents name space conflicts from the very beginning with the public domain and requires no further action on your part with that respect.

The only caveat is that you must configure Exchange URLs to the external URLs to support the certificate requirements.

Pros:

1. Easy to implement with minimal administrative overhead. Requires minimal action on administrators.

2. Prevents name space conflicts with external domain name. No one else owns it on the internet.

3. Forwarding works.

Cons

1. Domain name may look unprofessional. But this has nothing to do with anything on the public side (the internet).

2. VPN resolution difficult (like option 1) if DNS is not setup properly. That can be a sticky issue and depending on the VPN client will dictate whether it will work or not. I know one of the other MVPs (Dean Wells) created a little script to populate a user’s laptop or home PC’s hosts file with the necessary resources and would remove them once the VPN is dissolved.

3. Exchange HELO name must be altered in the SMTP properties (Exchange 2000 using MetaEdit, or SMTP properties in Exchange 2003), or in the Hub Transport properties (Exchange 2007) to accommodate anti-spam, SPF, and RBL software.

4. You won’t have any problems obtaining an Exchange 2007 & 2010 UC/SAN certificate since the internal name is not a public name and there’s nothing to check registration-wise by the Certificate Authorities when requesting the certificate with the internal Exchange FQDN.

 

==================================================================

Exchange 2007, 2010 and 2013 UC/SAN certificate considerations

More things to consider concerning the internal AD DNS domain name and if using Exchange 2007

If you choose a TLD, be sure to not choose one that is already in use by another entity. Reason is it will cause due confusion, and will create problems if you were to get an Exchange 2007 UCC/SAN certificate and adding a name for the internal namespace on the certificate. Here are some existing TLDs that you do not want to choose if the name does not belong to your entity:

So it would be a bad choice for the complications that will arise, if you name the internal domain is registered by others.

As far as choosing what name to use internally, there are pros and cons of using your public TLD (whether the same namespace or not), or a private TLD. I prefer a private TLD. You also have to take into consideration if you will be using Exchange 2007 and expect to purchase a UC/SAN certificate. This type of cert has multiple names, and the internal Exchange server’s private FQDN will be part of it. So for instance, your company is called “A Big Company”, and your external name is abc.com. You decide to make your internal name abc.net. However you never purchased abc.net from the registrar, and someone else did. So the Exchange server internal name is exchange.abc.net. In such a case, the CA will not approve it because A Big Company is not the registered owner of abc.net at the registrar (when you do a WHOIS) and is owned by someone else.

Technically speaking, you can also use the same name for the internal domain and the external domain. Just understand the ramifications. You may encounter the following possible issues that you may have to perform a domain rename in the future.

1.  If the internal domain name that you chose is the same as your Internet public domain name, internal clients may get the domain external IP but routers and firewalls will not respond from an internal request to the external interface. Some refer to this as a U-Turn, and firewalls, routers and NATs cannot handle U-Turns for port forwarded services.

2. Worse, if the internal name you chose was registered by another entity.

Generic top-level domains:

biz .com .info .name  .net  .org  .pro  .aero  .asia  .cat  .coop .edu 
gov .int  .jobs  .mil .mobi  .museum   .tel  .travel

Country-Code Top-Level Domains

You must be careful choosing, especially if someone else owns it on the internet. You’ll never get the cert approved if it is owned by someone else, despite the argument that “it’s my internal domain name…”

ac  .ad  .ae  .af  .ag  .ai  .al  .am  .an  .ao  .aq  .ar  .as  .at  .au 
aw  .ax  .az  .ba  .bb  .bd  .be  .bf  .bg  .bh  .bi  .bj  .bm  .bn  .bo 
br  .bs  .bt  .bw  .by  .bz  .ca  .cc  .cd  .cf  .cg  .ch  .ci  .ck  .cl 
cm  .cn  .co  .cr  .cu  .cv  .cx  .cy  .cz  .de  .dj  .dk  .dm  .do  .dz 
ec  .ee  .eg  .er  .es  .et  .eu  .fi  .fj  .fk  .fm  .fo  .fr  .ga  .gd 
ge  .gf  .gg  .gh  .gi  .gl  .gm  .gn  .gp  .gq  .gr  .gs  .gt  .gu  .gw 
gy  .hk  .hm  .hn  .hr  .ht  .hu  .id  .ie  .il  .im  .in  .io  .iq  .ir 
is  .it  .je  .jm  .jo  .jp  .ke  .kg  .kh  .ki  .km  .kn  .kp  .kr  .kw 
ky  .kz  .la  .lb  .lc  .li  .lk  .lr  .ls  .lt  .lu  .lv  .ly  .ma  .mc 
me  .md  .mg  .mh  .mk  .ml  .mm  .mn  .mo  .mp  .mq  .mr  .ms  .mt  .mu 
mv  .mw  .mx  .my  .mz  .na  .nc  .ne  .nf  .ng  .ni  .nl  .no  .np  .nr 
nu  .nz  .om  .pa  .pe  .pf  .pg  .ph  .pk  .pl  .pn  .pr  .ps  .pt  .pw 
py  .qa  .re  .ro  .rs  .ru  .rw  .sa  .sb  .sc  .sd  .se  .sg  .sh  .si 
sk  .sl  .sm  .sn  .sr  .st  .sv  .sy  .sz  .tc  .td  .tf  .tg  .th  .tj 
tk  .tl  .tm  .tn  .to  .tr  .tt  .tv  .tw  .tz  .ua  .ug  .uk  .us  .uy 
uz  .va  .vc  .ve  .vg  .vi  .vn  .vu  .wf  .ws  .ye  .za  .zm  .zw

 

 

==================================================================

Related Links

For a broad overview of this topic, read some of the links below.

Creating Internal and External Domains
http://technet.microsoft.com/en-us/library/cc755946(WS.10).aspx

DNS Namespace Planning
http://support.microsoft.com/default.aspx?scid=kb;en-us;254680

Assigning the Forest Root Domain Name:
http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbc_logi_kqxm.asp

 

=================================================================

Summary

I hope this helps in your endeavor.

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_image002[6] clip_image004[6] clip_image006[6] clip_image008[6] clip_image010[6] clip_image012[6] clip_image014[6]

 

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.

Suggestions, comments and corrections welcomed!