Namespace planning for DNS

Namespace planning for DNS

Before you begin using DNS on your network, decide on a plan for your DNS domain namespace. Coming up with a namespace plan involves making some decisions about how you intend to use DNS naming and what goals you are trying to accomplish in using DNS. Some questions you might have at this stage include the following:

Have you previously chosen and registered a DNS domain name for use on the Internet?

Are you going to set up DNS servers on a private network or the Internet?

Are you going to use DNS to support your use of Active Directory?

What naming requirements do you need to follow when choosing DNS domain names for computers?

Each of these questions is further discussed in the following sections.

Choosing your first DNS domain name

When setting up DNS servers, it is recommended that you first choose and register a unique parent DNS domain name that can be used for hosting your organization on the Internet, for example, "microsoft.com". This name is a second-level domain within one of the top-level domains used on the Internet. For a list and description of the most common top-level domains used on the Internet, see Top-level domains.

Once you have chosen your parent domain name, you can combine this name with a location or organizational name used within your organization to form other subdomain names. For example, if a subdomain were added, such as the itg.example.microsoft.com domain tree (for resources used by the information technology group at your organization), additional subdomain names could be formed using this name. For instance, a group of programmers working on electronic data interchange (EDI) in this division could have a subdomain named edi.itg.example.microsoft.com. Likewise, another group of workers providing support in this division might use support.itg.example.microsoft.com.

Before you decide on a parent DNS domain name for your organization to use on the Internet, perform a search to see if the name is already registered to another organization or person. The Internet DNS namespace is currently managed by the Internet Network Information Center (InterNIC). In the future, other domain name registrars might also be available.

DNS namespace planning for Active Directory

If you are using Active Directory, you need to first establish a namespace plan. Before a DNS domain namespace can be properly implemented, the Active Directory structure needs to be available. Therefore, begin with the Active Directory design and support it with the appropriate DNS namespace. Upon review, if you detect unforeseen or undesirable consequences for either of your plans, make revisions as needed.

Active Directory domains are named with DNS names. When choosing DNS names to use for your Active Directory domains, start with the registered DNS domain name suffix that your organization has reserved for use on the Internet, such as microsoft.com and combine this name with either geographical or divisional names used in your organization to form full names for your Active Directory domains.

For example, the test group at Microsoft might call their domain test.example.microsoft.com. This method of naming ensures that each Active Directory domain name is globally unique. And, once employed, this naming method also makes it easy to use existing names as parents for creating additional subdomains and further grow the namespace to accommodate new departments within your organization.

For a small organization using only a single domain or a small multidomain model, planning can be straightforward and follow an approach similar to the previous examples. For a larger organization using a more complex domain model, refer to additional Microsoft resources. For more information, see Using the Windows Deployment and Resource Kits.

Caution

When planning your DNS and Active Directory namespace, it is recommended that you use a differing set of distinguished names that do not overlap as the basis for your internal and external DNS use. As an example, assuming your organization's parent domain name is "example.microsoft.com"

For internal DNS names usage you could use a name such as "internal.example.microsoft.com"

For external DNS names usage you could use a name such as "external.example.microsoft.com"

By keeping your internal and external namespaces separate and distinct in this way, you enable simplified maintenance of configurations such as domain name filter or exclusion lists.

Choosing names

It is strongly recommended that you use only characters in your names that are part of the Internet standard character set permitted for use in DNS host naming. Allowed characters are defined in Request for Comments (RFC) 1123 as follows: all uppercase letters (A-Z), lowercase letters (a-z), numbers (0-9), and the hyphen (-).

For organizations with a prior investment in Microsoft NetBIOS technology, existing computer names might conform to the NetBIOS naming standard. If this is the case, consider revising the names of your computers to the Internet DNS standard.

The process of adjusting your naming conventions might prove to be time consuming. To ease the transition from NetBIOS names to DNS domain names, the DNS Server service includes support for extended ASCII and Unicode characters. However, this additional character support can only be used in a network environment with computers running Windows 2000 or a product in the Windows Server 2003 family. This is because most other DNS resolver client software is based on RFC 1123, the specification that standardizes Internet host naming requirements. If a nonstandard DNS domain name is entered during setup, a warning message appears recommending that a standard DNS name be used instead.

In networks running Windows NT 4.0 and earlier, a NetBIOS name is used to identify a computer running a Windows operating system. In networks with computers running Windows 2000 or a product in the Windows Server 2003 family, a computer can be identified in any of the following ways:

A NetBIOS computer name, which is optional and is used for interoperability with earlier Windows systems.

The full computer name. This is the default name for the computer.

In addition to these, a computer might also be identified by the FQDN comprised of the computer (host) name and a connection-specific domain name, where one is configured and applied for a specific network connection on the computer.

The full computer name is a concatenation of both the computer name and the primary DNS suffix for the computer. The DNS domain name for the computer is part of the System properties for the computer and is not related to any specifically installed networking components. However, computers that do not use either networking or TCP/IP do not have a DNS domain name.

The following table is a comparison of NetBIOS and DNS computer names.

Supports RFC 1123 and UTF-8. You can configure the DNS server to allow or disallow the use of UTF-8 characters. You can do so on a per-server basis. For more information, see Unicode character support.

63 octets per label. 255 bytes per FQDN (254 bytes for the FQDN plus one byte for the terminating dot).

The same as standard DNS with the addition of UTF-8 support. Character count is insufficient to determine size because some UTF-8 characters exceed one octet in length. Domain controllers are limited to 155 bytes for an FQDN. Domain controllers are limited to 155 bytes for an FQDN.

15 bytes in length.

To ensure interoperability between NetBIOS and DNS naming in Windows, a new naming parameter called the NetBIOS computer name was introduced. The value of this parameter, which is not required in a Windows 2000 or Windows Server 2003 environment, is derived from the first 15 characters of the DNS full computer name.

When the full computer name is a combination of the computer name and the primary DNS suffix for the computer, the impact of renaming and making the transition from a NetBIOS namespace to a DNS namespace can be minimal. Users continue to focus on the short computer name. If this name is 15 characters or less, it can be made identical to the NetBIOS computer name. The administrator can then also assign a DNS domain name for each computer. This can be done using remote administration tools.

In this way, the System properties page can have the following settings on the Computer Name tab (or its related dialog boxes):

Computer name

longer-than-15characters-name

NetBIOS computer name

longer-than-15c

Primary DNS suffix for this computer

example.microsoft.com

Important

By default, the primary DNS suffix portion of a computer's fully qualified domain name (FQDN) must be the same as the name of the Active Directory domain where the computer is located. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. This attribute is created and managed by the domain administrator using Active Directory Service Interfaces or the Lightweight Directory Access Protocol (LDAP).

In addition to the primary DNS domain name for a computer, connection-specific DNS names can be configured. For more information, see Configuring multiple names.

Because DNS host names are encoded in UTF-8 format, they do not necessarily have only 1 byte per character. ASCII characters are 1 byte each, but the size of extended characters is more than 1 byte.

Some non-Microsoft resolver software supports only the characters listed in RFC 1123. If you have any non-Microsoft resolver software, that software is probably not able to look up computers with names that have non-standard characters.

A DNS server that does not support UTF-8 encoding might accept a zone transfer of a zone containing UTF-8 names, but it cannot write back those names to a zone file or reload those names from a zone file. Therefore, you must not transfer a zone that contains UTF-8 characters to a DNS server that does not support them.

Integration planning: Supporting multiple namespaces

In addition to support for the internal DNS namespace, many networks require support for resolving external DNS names, such as those used on the Internet. The DNS Server service provides ways to integrate and manage disjointed namespaces where both external and internal DNS names are resolved on your network.

In deciding how to integrate namespaces, determine which of the following scenarios most closely resembles your situation and proposed use of DNS:

An internal DNS namespace, used only on your own network.

An internal DNS namespace with referral and access to an external namespace, such as referral or forwarding to a DNS server on the Internet.

An external DNS namespace, used only on a public network such as the Internet.

If you decide to limit the use of DNS as a name service within your private namespace, there are no restrictions on how it is designed or implemented. For example, you can choose any DNS naming standard, configure DNS servers to be valid root servers for your network's DNS distributed design, or form an entirely self-contained DNS domain tree structure and hierarchy.

When you start providing either referral to an external DNS namespace or full DNS service on the Internet, you need to consider compatibility between your private and external namespaces. Additionally, Internet service requires the registration of parent domain names for your organization.

When you add and connect to a DNS server for the first time using the DNS console, the root hints file (Cache.dns) is automatically primed for use on your network. This occurs transparently and does not require that you take any further action for this to be done.

Depending on how you use DNS, you can update this file in one of the following ways:

If you are connected to the Internet, you can either edit or update the local root hints file when the Internet root hints file (Named.root) is updated and released by the owners of the Internet root zone. For a current copy of this file, you can use anonymous FTP to the InterNIC Web site.

If you are not connected to the Internet, you can remove the default resource records contained in this file and replace them with NS and A resource records for the DNS authoritative servers at the root domain of your site. For root domain servers on your private network, you can safely remove this file entirely because servers operating at this domain level do not require or use a cache of root hints.

If you delete the Cache.dns file for a private root domain server when you have configured the DNS Server service using the From file method, you also need to remove the cache directive from the server boot file before restarting the DNS Server service.