Naming Conventions for Windows Server 2008

Accordingly, this also means that the two technologies may either exist by themselves or coexist in the same environment. Furthermore, these technologies can be implemented either externally or internally. In the following sections, I'll discuss some of the most common usage scenarios for name resolution tactics and how they're implemented in an enterprise-level environment. I'll begin with a brief review of DNS and zone types. Then, since I've already covered WINS technology, I'll address the incorporation of WINS with DNS, and then I'll address how to include Active Directory within DNS. Afterward, I'll finish off this discussion on naming conventions by talking about some of the most commonly used migration, delegation, and transfer strategies used in a complex environment.

1. Internal and External Namespaces

When I reference the words internal and external in regard to namespaces, I'm actually referring to whether you're using the internal infrastructure of your enterprise, or how that enterprise is accessed from the Internet. On the internal level, you usually reference your enterprise by an extension such as .local, whereas the external namespace is referenced by a top-level domain such as .net, .com, or .org. And each of these types of naming conventions, internal and external, make way for several configuration options that are important in terms of administrative overhead and user accessibility.

In fact, the first design choice an administrator has to make when choosing an internal and external naming scheme is whether that naming scheme will actually be the very same scheme, that is, whether the internal and external naming address will be the same. It's certainly a tempting option, and it has lulled more than a fair share of (perhaps lazy is too strong a word) less involved administrators.

When designing an internal namespace and an external namespace that use the same name, an administrator is choosing to have the internal namespace be a subdomain of the external namespace. The problems with this are, first, security based (because resources are all in one place) and, second, that users in the internal organization won't be able to access external resources without a lot of overhead administrative work, which is basically taking away from one of the benefits of using them both at once.

When using different internal and external naming addresses, you're provided with the added benefit of security, and you create an additional forwarder in DNS. Plus, users who may be accessing your network externally will not have access to your internal resources, which is a huge benefit.

1.1. External Namespace Design

The first step in choosing an external namespace design is to determine the most appropriate registered domain according to your company. For instance, if your company name is MyCorp, it would be logical to attempt to register the MyCorp.com domain with a given domain registrar, such as domainsdoneright.com. Once this is complete, you can begin your design from the top down.

An important point to keep in mind about any good external strategy is that a good design practice is to keep any external resources assigned completely as external resources. This means that it's a good idea to not place your external users, or Active Directory objects, in a completely different place that cannot access your internal resources. The reason this is suggested is because if internal resources, such as a printer, can be accessed on the external namespace, it's possible that an external user can take control of this device or cause internal problems within your enterprise, which is never a good thing.

By the same token, certain specialty resources such as a web proxy server needn't be located in the external namespace. This is mostly because resources such as this don't rely upon being addressed externally and make use of preexisting conditions in the internal namespace in order to operate. But the most important reason for the separation of the external namespace is NAT. When using NAT, it's difficult for external addresses to be accessed by the internal network because of the inherent problems with referencing something else in another domain or possibly a different subnet.

1.2. Internal Namespace Design

The reasons for implementing an internal namespace design are many. One of the reasons for this portion of the naming convention design is that there needs to be an isolated area within your network that can be accessed only by authorized resources from within a certain area or that falls within the purview of a predefined set of security conditions for external access that is laid out originally by the enterprise administrator. But more important, the point of an internal namespace design is to create a robust design that creates an environment that provides a method for name resolution of all internal clients through the use of either hostnames or NetBIOS names.

2. Zone Types and Zone Transfers

Windows Server 2008 has four types of zones: primary, secondary, stub, and GlobalNames. And each of these zones is designed for a specific purpose that can be incorporated with Active Directory. Throughout your study, you've already touched on a good share of these zone types, but for the sake of completeness you can review each of these shortly.

2.1. Primary Zones

A primary zone is the main standard zone type in Windows Server 2008. It can be either integrated or not integrated with Active Directory. The primary zone contains the main database associated with the DNS and is usually supported by secondary zones. If Active Directory is not associated with it, the primary zone hosts the only modifiable zone in the infrastructure, with all remaining zones being secondary to it. If it is integrated with Active Directory, the zone data is copied into Active Directory, and all other associated zones become peers of this zone. It is, by far, the most efficient way of managing DNS zones. On the enterprise level, it is highly recommended to integrate DNS with Active Directory; otherwise, the standard primary zone becomes a bottleneck for the rest of the enterprise that relies upon the primary zone to receive information from Dynamic DNS or other query resolution processes.

2.2. Secondary Zones

Secondary zones are zones set apart from the primary zone to aid in the replication and accessibility of DNS database records for the rest of the enterprise. Secondary zones are read-only, host a copy of known DNS information, and reduce traffic in an enterprise. Secondary zones are usually placed at logical places throughout the external and internal namespaces in order to aid users on either side in the acquisition of whatever DNS information they may require.

2.3. Stub Zones

Stub zones are not new to Windows Server 2008 but are still a relatively new concept to Windows Server in general. Originally released with Windows Server 2003, stub zones are zones that delegate information to another namespace. The main purpose of a stub zone is to act as a buffer between zones to eliminate traffic caused by excessive queries to a particular zone by delegating requests to another namespace. Stub zones receive their updates by an authoritative server and contain only the following:

• Start of authority (SOA)

• Name server (NS)

• Address (A)

Once it receives this information, the stub zone periodically updates itself whenever it requires additional information from its authoritative server based on administratively defined settings.

2.4. GlobalNames Zone

The completely new zone type in Windows Server 2008 is the GlobalNames Zone, which I briefly discussed earlier. It is a zone type that is designed to assist in phasing out the WINS technology by implementing a last-resort technique that resolves NetBIOS queries for DNS operating infrastructures. It supports IPv6, can integrate into a currently running WINS environment, and can affect an entire forest.

2.5. Zone Transfers

Within Windows Server 2008, zone transfers come in two types: authoritative transfers (AXFRs) and incremental zone transfers (IXFRs). An AXFR is a complete transfer of all components of the zone as it is authoritatively initiated, whereas an IXFR transfers only the differences since the last zone transfer. Normally, most organizations try to make as much use as possible of IXFR because of the inherently less bandwidth that is used.

3. Active Directory Replication with DNS

A friend of mine once told me that if Active Directory knew where, when, and how to replicate itself, I'd probably be out of a job. And, unfortunately, I have to agree. One of the major problems with any enterprise is the process of connecting various servers through the use of site links, bridges, and various routers across multiple subnets. It's time-consuming, difficult, and not necessarily reliable. Additionally, replication uses schedules that may not fit in perfectly well with your given organization.

However, the actual process of setting up replication was mostly covered in your exam on Active Directory. On this certification exam, you'll be concentrating on understanding the scope of your replication as it pertains to DNS. Remember, there are four scope levels, which are summarized in Table 1.

4. DNS Server Requirements and Placement

The exact DNS server requirements of your organization will be based on the number of users, the amount of queries, and the amount of traffic that you see both externally and internally within your organization. As a general rule of thumb, a resource record (RR) will take up approximately 100 bytes of RAM. Thus, based on the number of users and records associated with your organization, you can use this accordingly. If you are in an organization with 10,000 users, you will require 1,000,000 bytes of RAM just for resource records that can be accessed thousands of times per second based on the amount of traffic flowing back and forth between your network.

In general, the basic rule of DNS server requirements is that the DNS server must be highly available and accessible to all users in your organization. In an ideal world, this would mean you could place a DNS server in every subnet, and each server would have an incredibly light load. However, for an organization with, say, 500 subnets, this is not very realistic. This problem literally doubles when you consider that the first rule of thumb with network design is that you plan for the worst and then expect the worst. So, this means you will naturally need a backup DNS server for each server you are using. And, in your ideal "500 subnet" design, you'd be using a paltry 1,000 servers purely for DNS—probably not a good idea.

Normally, DNS servers are accessed across a WAN link or across routers that are connected in such a way that allow for easy throughput. When placing your DNS servers in design questions on the certification exam, consider the speed or your WAN links as well as the speed of the given switches in the topology, and place your DNS server in the most logical area of your network in terms of accessibility.