Wadeware Uses Existing DNS
Wadeware has determined that it is going to use an existing DNS installation for the integration with Active Directory. The current installation is a UNIX-based installation that is supported by a group of UNIX Administrators. They are the team that created the initial installation. They are knowledgeable about DNS, and they have kept the software version for DNS within a couple of point releases of the latest version.
You are already familiar with the main requirement for Active Directory (that is, incremental to the typical functionality of DNS). The incremental requirement for DNS is support of the service record (SRV) resource record.
There is a preferred feature of late DNS versions that is a "nice-to-have" feature. This feature is incremental zone transfers. Microsoft's DNS supports this feature. Incremental zone transfers provide for a more efficient use of network bandwidth. Rather than sending the entire zone file across the network to all the secondaries each time a change is made, only the records that are changed are sent between the DNS servers. This can reduce network traffic.
Design Considerations
There are several design considerations in implementing DNS for Active Directory. When designing DNS for Active Directory, consider the following list:
With Internet connectivity, the root of your DNS space should be unique to the entire Internet. If possible, pick a name that is unique on the Internet, and register the name. If your access to Active Directory is for internal use, you can also take your external DNS name and convert it to a .local address. Therefore, for Wadeware.net, you would create an internal domain name of Wadeware.local.
You should consider your namespace as either contiguous or disparate. If your namespace is not contiguous, a multiple-tree Forest implementation is required, and each tree name should be registered for an Internet registered name.
Long Term Goal
With Wadeware, you have determined that your long-term goal is to have a single DNS technology. You do not have a mandate for this, but you suspect that a single technology will reduce administration, ongoing support, and training costs in the long run. Your hope is to also consolidate DNS administration and Active Directory administration.
Now that you have determined that you would like to have a single focus for DNS administration, you want to make sure that your DNS design does not preclude you from using the Microsoft DNS as the primary server. You are aware that in the short run you need to coexist with the current environment. You have determined that you will handle the migration in two phases.
The first phase is for you to start Active Directory implementation while keeping Wadeware's existing DNS implementation active for most of the users. This first phase is used by a pilot group of users and administrators. The final phase is to supplant the current DNS with the Microsoft DNS.
A second consideration is how you are going to treat your integration with the Wadeware's Internet presence. There are two options here as well.
First, you could have a single DNS namespace both for your internal name resolution and external name resolution. Another approach is to have an external presence, such as Wadeware.net, and a separate internal presence, such as Wadeware.local. No .local resources can be accessed from outside the firewall or the proxy of Wadeware.
You decide on using a single DNS namespace. You decide on this for two reasons. Your existing implementation has a single namespace, and this has provided the security that you needed. You have hosts that relay external connections to hosts internally that provide the requested service. These are called bastion hosts. The bastion hosts are on an isolated LAN coming off your existing firewall router as part of the implementation. Although this has required some additional configuration between firewall rules and server software configuration, you are convinced that this provides the security you need. The original thinking is that this should largely remain a static configuration after it is configured to meet your security requirements.
Your current implementation provides for two primary DNS configurations, one for the external name resolution, and one for the internal resolution. The internal DNS server provides name resolution for all the internal and external resources. This is depicted in Figure 8.3.
Figure 8.3. Wadeware's firewall implementation.
There is a network segment that is exposed to the Internet. This segment only exposes the mail server and the Web server. A single external DNS server has redundancy support from a server at your Internet service provider (ISP). The internal DNS server provides resolution of all name resolution requests for internal resources and forwards requests for external resources. These two servers represent the two network segments. In this example, there are three externally exposed servers, each providing support for a single application. The three servers are for mail, DNS, and Web support.
With this approach, resources (such as Web servers or email exchangers) can be located in a separate subnet or isolated LAN also referred to as the demilitarized zone (DMZ) , which reduces the possibility of a security breach.
There are two DNS configurations for Wadeware. The external DNS configuration is relatively simple. This configuration contains the information for address resolution of Web services and the mail server. The internal DNS server provides name resolution for all the servers in the organization that provide services for internal use (for example, fileserver.Wadeware.net. The internal DNS server also provides name resolution for the mail server and Web servers. These entries are for the internal and direct address, not the same address that is given out on the external DNS server. Finally, the internal DNS provides forwarding for addresses that do not reside internally. An example of this functionality would be a user who needs resolution on a http://www.microsoft.com. The address is resolved by the ISP's name server. The configuration for Wadeware's external view is as follows:
;
; File: db.wadeware
;
Wadeware.net. IN SOA server1.Wadeware.net. postmaster.Wadeware.net. (
1999020777 ; serial [yyyyMMddNN]
21600 ; refresh [6h]
3600 ; retry [1h]
691200 ; expire [8d]
86400) ; minimum [1d]
;
; Nameservers
Wadeware.net IN NS server1.Wadeware.net.
Wadeware.net IN NS server.someISPout-there.com
localhost.Wadeware.net IN A 127.0.0.1
mailpo.Wadeware.net IN A 149.55.44.32
ftp.Wadeware.net IN A 149.55.44.32
www.Wadeware.net IN A 149.55.44.41
mailpo2.Wadeware.net IN A 149.65.44.32
Wadeware.net. IN MX 0 mailpo.Wadeware.net.
Wadeware.net. IN MX 10 mailpo2.Wadeware.net.
The internal DNS table for internal name resolution looks like the following:
;
; File: db.wadewareinternal
;
Wadeware.net. IN SOA server1.Wadeware.net. postmaster.Wadeware.net. (
1999020777 ; serial [yyyyMMddNN]
21600 ; refresh [6h]
3600 ; retry [1h]
691200 ; expire [8d]
86400) ; minimum [1d]
Wadeware.net IN NS server1.Wadeware.net.
Wadeware.net IN NS server.someISPout-there.com
localhost.Wadeware.net IN A 127.0.0.1
server1.Wadeware.net IN A 149.55.44.31
mailpo.Wadeware.net IN A 149.55.44.32
ftp.Wadeware.net IN A 149.55.44.32
www.Wadeware.net IN A 149.55.44.41
mailpo2.Wadeware.net IN A 149.65.44.32
server2.Wadeware.net IN A 149.55.44.52
server3.Wadeware.net IN A 149.55.44.53
server4.Wadeware.net IN A 149.55.44.54
server5.Wadeware.net IN A 149.55.44.55
server6.Wadeware.net IN A 149.55.44.56
server7.Wadeware.net IN A 149.55.44.57
server8.Wadeware.net IN A 149.55.44.58
server9.Wadeware.net IN A 149.55.44.59
server10.Wadeware.net IN A 149.55.44.510
Wadeware.net. IN MX 0 mailpo.Wadeware.net.
Wadeware.net. IN MX 10 mailpo2.Wadeware.net.
kerberos.tcp.Wadeware.net 600 SRV 0 100 88 server2.Wadeware.net
ldap.tcp.Wadeware.net 600 SRV 0 100 389 server2.Wadeware.netYou should note that the internal configuration provides information about additional servers (servers 2 through 10). The SRVs are also in use for pointing to the server that provides the Kerberos and Lightweight Directory Access Protocol (LDAP) services. These files do not represent a complete set of DNS configuration files, but they give an idea of how Wadeware's DNS configuration starts out.
Phase 1
In Phase 1, you have a pilot group and a segmented network infrastructure so that DHCP is supported by Microsoft DHCP. Now you are going to add Windows 2000 with Active Directory. You want Active Directory to rely on this DNS, and the DNS needs to be changed so that Active Directory servers are able to provide resolution by using DNS. This presents an important question. What is going to be the root domain name for your Active Directory tree? You cannot use Wadeware.net because the existing DNS is the SOA for Wadeware.net.
If you decide to create a sub-domain under Wadeware.net, such as usa.Wadeware.net, you need to modify the DNS to support this, and more importantly you are not able to have Wadeware.net as the root.
Another option is to rebrand your identity with the eventual movement to Active Directory and Windows 2000 DNS. This would enable you to create a new tree with the new domain name. Instead of Wadeware.net, you would create a tree with the new name, Wadeware.local. Externally, your identity can remain Wadeware.net.
The other question that is implied is whether you are going to create a Forest or a tree. For Wadeware, the answer is a Forest. This gives you the capability to have a non-contiguous namespace. The best solution for the name is to start out with Wadeware.local and then add sub-domains or additional trees as the need arises.
Phase 2
During Phase 1, you demonstrated that Microsoft's DNS performs well as a DNS server. You have demonstrated that it can function as a primary server and interoperate with the existing DNS. You have also demonstrated, in production use, the advantages of DHCP and DDNS using these features in the new domain that you created for a pilot group in your organization.
Now is the time to transition your environment to a strictly Microsoft DNS. This can take two tracks. The first is to completely eliminate the existing DNS structure and migrate it fully in the Windows 2000 DNS. You can do this by creating a new tree for the Wadeware.net namespace. The second track is to leave the internal namespace based on the Windows 2000 DNS and the external namespace on the UNIX-based DNS for the Wadeware.net domain. This is a modest compromise although it does reduce some of the benefits of the single point of administration.