Designing the DNS Namespace
The DNS namespace that you choose for your organization will be used for more than identifying computers on your network. Internet users accessing web resources will identify you with your external domain name. Active Directory will be based on the name that you decide to use internally. The choices you make at the design level stage will impact the rest of the name infrastructure.
In Chapter 2, Determining Business and Technical Requirements, and Chapter 3, Designing the Active Directory Forest Structure, we discussed options for naming your forest root domain and the domains within that make up the trees within your forest. If you are working through this book from beginning to end, you should have already created a domain name design for Active Directory. Your DNS domain names will have to be identical to the domain names you have chosen for Active Directory.
Even if you have decided upon a domain name scheme for Active Directory, you should go back and review your decisions. As you are designing the DNS infrastructure to support your Active Directory design, you may find that the existing infrastructure is not conducive to the design that you wanted to put in place. Several things may get in your way, the first of which could be the political infighting you will encounter if you tell the current DNS administrators that you are taking over their DNS with yours. You may need to find a tactful method of working with the existing DNS administrative staff when you try to interoperate with their infrastructure.
Depending on your current environment, you have the following options available to you:
The existing infrastructure uses a legacy Microsoft DNS implementation. Windows NT 4 Server s DNS service conforms to DNS domain naming guidelines. The current namespace could be used if you are moving to a Windows Server 2003 DNS solution. If you are going to implement Active Directory, you will have to either upgrade the existing DNS servers to Windows Server 2003, or replace them with Windows Server 2003 DNS servers to support Active Directory within the network infrastructure.
The existing infrastructure uses a third-party DNS solution that adheres to standard DNS guidelines. If the third-party DNS solutions follow the DNS domain naming guidelines, you will not have to change the namespace design. However, if you are going to use Active Directory, you will need to make sure that the third-party DNS server has the correct features to support Active Directory. If the server does not you are left with the option of upgrading the current server to a version that does support Active Directory or you will have to integrate Windows Server 2003 DNS servers into the infrastructure.
The existing infrastructure uses a third-party DNS solution that does not adhere to standard DNS guidelines. If the third-party DNS solution does not conform to DNS domain naming guidelines, you will have to upgrade or redesign your DNS infrastructure to conform before implementing Windows Server 2003 DNS servers or Active Directory.
No DNS solution exists and you are implementing a new Microsoft Windows Server 2003 DNS. If you are simply implementing a DNS infrastructure, you need to design your domain names according to the organization s needs. If you are deploying Windows Server 2003 DNS to support Active Directory, follow your Active Directory naming requirements when you design the domain namespace.
The existing infrastructure uses a namespace that you do not want to use for Active Directory, but you do not want to redesign the current namespace. Either create an Active Directory namespace that will be a child of the existing namespace so that you can separate the two namespaces, or create a new namespace that will be used in conjunction with the existing namespace.
Prior to implementing DNS zones, you need to know the names that you will need to support for your organization. In the following section we will take a look at the namespace requirements for internal and external domain names.
Determining Internal and External Namespace Requirements
You essentially have two options when you are creating a DNS namespace for your internal infrastructure and your Internet presence: you can use the same namespace internally as you do externally, or you can create a different namespace for each. Either way, you will need to support two DNS server infrastructures . If your internal and external namespaces are the same, you will have more administrative overhead as you synchronize data so that internal users are able to access your company s external resources.
In the following sections we will examine the options that can be used when designing the namespace and the root domain requirements.
Identifying Namespace Options
Most organizations will separate the domain names so that the internal DNS namespace is either a subdomain of the external namespace, or the two namespaces are completely different. Although this will increase the administrative overhead because all of your internal and external resources will not be located in the same domain, you will add an additional level of security to your infrastructure.
Figure 10.1 illustrates a company that has used the same namespace internally as they have externally.
Figure 10.1: Using the same domain name internally and externally
The primary problem with using the same namespace is that internal users will not be able to access the organization s external resources without additional administrative work. DNS records for the external resources will have to be added to the internal DNS server so that the users can access them, or the resources will have to be hosted on both internal and external servers and synchronized to keep them both up to date.
Figure 10.2 illustrates an organization that has implemented separate namespaces so that the internal and external domain names are not the same. This still adds security to your design due to the fact that external users will not have access to your internal namespace, yet you can configure DNS to allow internal users to access the external resources.
Figure 10.2: Using a separate domain name internally than is used externally
External users will be able to access your external resources, but they will not have access to the internal resources because the external DNS servers will not have records for the internal namespace. Internal users will have access to internal resources because the internal DNS servers will control the internal namespace. When internal users want to access external resources, the internal DNS servers can forward the request to the external DNS servers.
When separating the namespaces, a common practice is to use the subdomain ad for the internal namespace. For example, a company that uses zygort.com as their Internet presence could use ad.zygort.com as their internal namespace.
Another option when you are using a different namespace is to have completely separate namespaces. Whereas the aforementioned company could use zygort.com as their Internet presence, they may adopt zygort.local internally. The top-level domain local that is used here, or any name that is not defined as a top-level domain for the internet, will work to create a separation from the internal namespace and the external. You should try to determine a top-level domain name that you do not anticipate being used on the Internet so that you do not cause name resolution issues at a later date.
Identifying Root Domain Requirements
Using an internal DNS root allows you to implement a namespace that is identified as the only DNS infrastructure available. Instead of using top-level domains on the Internet, your DNS infrastructure would be seen as the highest level in the DNS hierarchy. When a client queries for a hostname, if the DNS server they are configured to use does not have entries for the domain of the host they are trying to contact, your DNS root will be contacted. If your DNS infrastructure does not have entries for the host, or forwarding of queries outside of your organization is not configured, the client will not be able to locate the host they are querying.
Because your DNS infrastructure is seen as the top level in the hierarchy, you will have to make sure that you have delegations for all of the domains for which you are authoritative . For example, if you have a company that hosts an internal DNS root, you would have to create delegations to each of the namespaces within your organization. Zygort, Inc. uses the domain name zygort.lcl . They also have a secondary company that uses the domain name bloomco.lcl . If a user with a computer in the zygort.lcl namespace wants to obtain the IP address for the computer with the hostname host1.bloomco.lcl , the DNS servers for zygort.lcl need to have a delegation record that identifies the name servers for the bloomco.lcl domain.
When you use an internal DNS root, the clients on your network will not use DNS servers on the Internet to resolve hostnames. This gives you an additional level of security because you will not pass any of your internal DNS information to servers on the Internet. At the same time, if your clients cannot access DNS servers on the Internet, they will not be able to resolve hostnames outside of your DNS infrastructure. You are not able to configure a DNS server that contains the root of the DNS hierarchy as a forwarder. If this is the case, you will have to determine another method of allowing clients to connect to Internet resources, such as using a proxy server like Microsoft s Internet Security and Acceleration (ISA) server.
If your organization hosts DNS hierarchies that are top-level DNS namespaces, you will need to design a method of interoperability between the namespaces. The easiest method of interoperating is to add a delegation to the root DNS zone. This will allow queries to be passed to the root zone, which will in turn send a response that identifies name servers authoritative for the zone in question.
Another method for allowing multiple top-level domains to interoperate is to add a secondary zone for each domain to each DNS server in the other domains. These secondary zones will then contain the DNS data for each of the domains in the organization. Zone transfers will keep them up to date and clients will have local name resolution from their preferred DNS server. Having secondary zones for the other namespaces also alleviates the wide area network (WAN) traffic that is generated when a client sends a hostname query, but you will have to take into account the amount of WAN traffic that is generated from the zone transfer.
The final options for top-level domain interoperability is to configure each of the DNS servers to forward requests to another DNS server. You could configure conditional forwarding for each of the domains within your organization. Conditional forwarding will send the query to a DNS server based on the namespace that the query is destined for. For example, if you create a conditional forwarder for the DNS servers in zygort.lcl to forward queries destined for bloomco.lcl to a DNS server authoritative for the bloomco.lcl domain, whenever your server receives a query for bloomco.lcl , the query will be forwarded to a bloomco.lcl DNS server. All other queries would be sent to the DNS servers defined for all other domain queries.
Identifying Naming Standards
There are two namespace considerations you need to take into account. Every company needs to determine what name they will use for internal resources. If you need to have an Internet presence, you will need to determine what name will identify you to the world. Each of these namespaces will then be integrated into your organizations identity. It is not easy to change either of these namespaces, so choose wisely.
In the following sections, external and internal namespace options are identified. Take these into account as you design the namespaces for your organization.
Identifying External Namespace Options
If you have determined that your organization will need an Internet presence, you need to determine what name you will be identified with. Your name should identify your company. Users who are accessing your external resources should find your name easy to understand. One guideline is to make your name short yet understandable. The easier it is to remember and type, the easier it will be for users to return to your site. The name zygort.com is much easier to remember and type than zygort-manufacturing-inc.com. Plus, if you are using a subdomain as your internal name, the longer the external DNS name is, the longer the internal namespace will be as you append the subdomain. Users will not appreciate having to enter accountspayable.accounting.corp.zygort.lcl.
Verify that the name that you would like to use for your Internet presence is available. You can search the whois databases on sites such as www.networksolutions.com to find out if another company has registered the name. If your name has not been registered, configure a DNS server to be authoritative for a zone, which will host your namespace or have an ISP host the DNS records for you. Then make sure you register your name for use and provide the registrar with the DNS server address that will be hosting the zone.
Even if you are not initially planning on an Internet presence, you should register a domain name for your company. It never fails ”every time a company decides that they do not need to have an Internet presence, they turn around a couple of years later and change their minds. If someone else has previously registered the domain name that the company wants to use, they will have a hard time trying to obtain that name, or they will have to use another, less desirable name.
Identifying Internal Namespace Options
To keep your internal resources hidden from external users, you should keep the internal namespace different than the Internet namespace. If you wish to keep the two namespaces separate, you have the option of making the internal domain name a child domain from the Internet namespace or having two completely different namespaces.
Even if you never add any delegation records to the Internet domain so that the internal domain name is available from the Internet domain, you will still be using a domain name structure that will make sense to your users. If you decide to make the internal domain accessible, you can add a delegation record to the DNS servers that are used for your Internet presence or create a subdomain to allow specific servers to be accessed.
Make sure that you are not using a name that is already in use on the Internet. If you do, you could cause users to have name resolution issues. In addition to name resolution issues, if you were to decide to open up a portion of your internal network, you would not be able to because another entity owns the name.
You should also take some configuration options into account. First, you should not use one of the top-level domain names as the domain name of your internal network. Any of the top-level domain names like .com, .org, . edu , .us, and so on, should be reserved for top-level use only so that internal clients that have internet access do not become confused . You should also try to not use abbreviations or acronyms for any of your domain names that identify business units or divisions. Doing so could confuse your users when they are trying to locate resources, especially if separate business units use the same acronyms for different departments, or the department name changes during a reorganization. At the same time, you will have to make a trade-off when it comes to names that are difficult to spell or remember.
Businesses are in a constant state of flux. Attempt to use static identifiers so that reorganization will not adversely affect your domain design. A good example of a static identifier is a geographic location such as the city name where the office is located. This should safeguard you from having domain names that no longer describe their functions or use.
Identifying Computer Naming Options
Every computer within your infrastructure needs to have a unique name. Without a unique name, clients would become confused when they were trying to locate the host on which the resource they are trying to reach resides. Computers running Windows operating systems have two types of names within your network: hostnames or NetBIOS names.
Hostnames
Hostnames for systems that will be used with your DNS infrastructure should follow rules that you establish. If your organization already has a third-party DNS solution in place and you are going to continue using that solution or are planning on Windows Server 2003 DNS interoperating with that solution, you will need to follow the hostname naming conventions. Failure to do so could cause interoperability issues, such as records not being able to transfer from the Windows-based DNS servers to the third-party DNS servers.
To make migration from NetBIOS-based systems to DNS based, Windows Server 2003 s DNS service allows you to use the Universal Multiple-Octet Coded Character Set (UCS) Transformation Format 8 (UTF-8) naming conventions. Most third-party DNS servers do not support UTF-8. Instead, most of them support the American National Standards Institute (ANSI) character set. If your organization is going to use Windows-based DNS services exclusively, you can use any valid character as long as it follows the Windows computer name conventions.
| Note | For more information about character sets that are supported by traditional DNS zones, see RFC 952, Requirements for Internet Hosts - Application and Support at http://www.ietf.org/rfc/rfc952.txt. |
NetBIOS Names
NetBIOS names are the computer names that are configured for a system. When setting a computer name, you are allowed to use up to 15 characters , and every computer name must be unique. When designing the computer naming conventions that you will employ within your organization, you should first determine whether you will keep the computer name and the hostname the same. Doing so will make it easier for you to identify a system no matter which name resolution method is being employed.
For instance, if you want to keep the same names for both resolution methods , a server hosting e-mail for the Seattle office that is in the seattle.corp.com domain may be named SEAEXCH1 and its fully qualified hostname would be seaexch1.seattle.corp.com. Try to make the design as simple as possible so that your users will not have to be retrained on how to perform the tasks they are already familiar with.
Identifying Integration Options
The Windows Server 2003 DNS service was designed to interoperate with the latest DNS standards. It was also designed to support additional features that are only available to a Microsoft DNS implementation. These additional features are beneficial to administrators who want to have easier administration and additional security options.
Due to Windows Server 2003 s compliance with DNS standards, it will interoperate with Berkley Internet Name Domain (BIND) DNS servers running versions 9.1.0, 8.2, 8.1.2 and 4.9.7. Windows Server 2003 DNS is also fully compliant with Microsoft Windows NT 4 s DNS service.
As you will note in Table 10.1, Windows Server 2003 s DNS service and BIND 9.1.0 support some important DNS features. Other versions of DNS do not support all of the options.
| SRV Records | Dynamic Updates | Incremental Zone Transfer | Stub Zones | Conditional Forwarding | |
|---|---|---|---|---|---|
| Windows Server 2003 | X | x | x | x | x |
| Windows 2000 | X | x | x | ||
| Windows NT 4 | x | ||||
| BIND 9.1.0 | X | x | x | x | x |
| BIND 8.2 | X | x | x | ||
| BIND 8.1.2 | X | x | |||
| BIND 4.9.7 | X |
Additional features are present in a Windows Server 2003 DNS environment that are not supported by other DNS servers. A list of additional features is presented in Table 10.2.
| Secure Dynamic Updates | WINS Integration | UTF-8 Character Encoding | Active Directory Integrated Zones | Application Directory Support | Obsolete Record Scavenging | |
|---|---|---|---|---|---|---|
| Windows Server 2003 | X | x | x | x | x | x |
| Windows 2000 | X | x | x | x | x | |
| Windows NT 4 | x | |||||
| BIND 9.1.0 | ||||||
| BIND 8.2 | ||||||
| BIND 8.1.2 | ||||||
| BIND 4.9.7 |
When attempting to integrate Windows Server 2003 DNS into an existing environment, take the previously mentioned interoperability into account. If the existing infrastructure does not support some of the features, you may be forced to upgrade the current infrastructure to Windows Server 2003 DNS so that all of the features that you need for your design are met.
In many companies, a DNS infrastructure is already controlled by a DNS group. If this group is unwilling to relinquish control of DNS or will not allow you to implement your own Windows Server 2003 DNS server, you may be forced to use the existing DNS services. There are those organizations that have separate divisions that are responsible for specific portions of the network infrastructure. If your organization is one of these and you are not allowed to implement DNS due to departmental standards and regulations, you will be forced to use what the DNS administrative staff dictates. Be aware of the requirements for Active Directory, however. You may need to force them to upgrade their existing servers to handle the service locator (SRV) records and dynamic updates that Active Directory uses.
Designing Zones
After you have determined the namespaces that will support your DNS infrastructure, you will need to determine how your DNS servers will support the namespaces. Within a DNS solution, the records that are used by clients are stored in DNS zones. These zones are responsible for storing the records that identify the hosts and services within a DNS namespace. Because you have several zone type options, you need to understand how each of them functions and the advantages and limitations of each.
In the next few sections, we are going to look at the different zone types and how they can be used within your Active Directory infrastructure.
Identifying Zone Types
Three zone types are available within Windows Server 2003 DNS: primary, secondary, and stub zones. Any of these zones can be used as a standard zone type or can be integrated with Active Directory. Standard zones are stored as a file on the DNS server and are replicated to other DNS servers through a process known as a zone transfer. Active Directory “integrated zones store the zone information within Active Directory and replicate the zone information through Active Directory replication. If a non-Windows Server 2003 DNS server requests a zone transfer, an Active Directory “integrated zone will send the update via a zone transfer.
Primary zones are traditionally the zones in which changes to the zone data can be made. When a primary zone is a standard zone, that is, not Active Directory “integrated, it hosts the only modifiable copy of the zone. Any other DNS server that holds the same zone information would have to be a secondary zone. The secondary zone would then be updated through a zone transfer from the primary zone or another secondary zone acting as the master for the zone transfer. Once a primary zone is made Active Directory “integrated, the zone data is stored in Active Directory and all of the DNS servers hosting an Active Directory “ integrated copy of the zone become peers. The zone data can be modified on any of the servers and Active Directory replication will keep all replicas of the zone up to date.
Traditional primary zones do have a very serious limitation when is comes to an enterpriselevel environment; there is only one server within the zone to which changes can be implemented. In an organization that uses dynamic DNS in order to register the clients, each client will have to connect to the DNS server that hosts the primary zone to register. There are three main issues with this scenario. First, since each of the clients will have to contact the same server, you will have a bottleneck during busy registration periods. Secondly, if you are registering across WAN links, you will be using bandwidth for registration that may be needed for other services. Finally, the DNS server hosting the primary zone becomes a single point of failure. Active Directory “integrated zones alleviate each of these issues by making the primary zone redundant on each of the domain controllers that host the zone.
Secondary zones are read-only copies of the primary zone data. They are used to host a copy of the zone data close to the clients that need to use a local copy of the zone data so that WAN traffic is reduced or the client can access zone data from multiple zones on the same DNS server. You should use secondary zones at sites where you want to reduce the amount of Active Directory replication that is crossing WAN links or DNS servers that are not running Windows Server 2003 or Windows 2000.
Stub zones are new to Windows Server 2003. A stub zone is a zone that acts as a delegation to another namespace, but instead of an administrator having to update the delegation records every time an authoritative name server in the remote zone changes, the stub zone updates its entries by sending queries to a server that is authoritative for the remote zone. The stub zone only holds the start of authority (SOA) record, the name server (NS) records, and the address (A) records for the name servers. When the stub zone is created, a query is sent to the authoritative DNS server for the zone. This query asks for and populates the stub zone with the SOA, NS, and A records for the name servers. The refresh interval that is listed on the SOA record defines when the stub zone will request an update of the records. As with the primary zone, a stub zone can be either standard or Active Directory “integrated. Active Directory “integrated stub zones can be replicated to all DNS servers that are domain controllers.
Identifying Propagation Methods
As mentioned in the previous section, zone data can be passed from DNS server to DNS server in two methods: zone transfer and Active Directory replications. Depending upon your DNS infrastructure, you may not be able to use Active Directory “integrated zones. Even if all of your servers are running Windows Server 2003, if a DNS server is not a domain controller, you will have to use zone transfers to get data to it.
Zone Transfers
Zone transfers come in two flavors: authoritative zone transfers (AXFRs) and incremental zone transfers (IXFRs). An AXFR, sometimes referred to as a complete zone transfer, transfers the entire zone database when the zone transfer is initiated. An IXFR only transfers the changes in the zone since the last zone transfer. As you can probably guess, the amount of data that is transferred during an IXFR transfer could be substantially less than that of an AXFR.
The choice to use zone transfers is usually made because the DNS servers in your environment are not Windows 2000 “ or Windows Server 2003 “based. Third-party DNS servers do not participate in Active Directory replication, nor can they read the Active Directory database to determine the resource records that are used. To keep the network usage as low as possible, you should make sure the DNS servers all support IXFR. Otherwise, every time a zone transfer is initiated, the entire zone records will be passed to all of the appropriate DNS servers.
Active Directory Replication
Active Directory “integrated zones can take advantage of Active Directory replication to propagate the changes made to resource records. When you use Active Directory replication, not only do you have the additional benefit of only having one replication topology, but a smaller amount of data is usually passed across the network. For instance, take a record that changes a couple of times before the replication or zone transfer occurs. In the case of a zone transfer, if the record changes twice before the transfer is initiated, both changes have to be sent, even if some of the data is no longer valid. In the case of Active Directory replication, only the effective changes are replicated. All of the erroneous information is discarded.
You also gain the advantage of the built-in functionality of replication. In an environment where you have multiple sites, many of which could be connected through WAN links, if there is considerable amounts of zone information to be transferred, the replication traffic that is sent between domain controllers in different sites is compressed to reduce network overhead.
Windows Server 2003 DNS servers that host Active Directory “integrated zones also offer another feature that helps reduce the amount of traffic caused by keeping the DNS server in sync. Once you create an Active Directory “integrated zone, you have the option of determining the scope of replication for the zone. Four options are available:
-
Replicating to all DNS servers in the forest
-
Replicating to all DNS servers within a domain
-
Replicating to all domain controllers within the domain
-
Replicating to all domain controllers defined in the replication scope of a DNS application directory partition
If you choose the first option ”replicating to all DNS servers within the forest ”every DNS server within the forest will receive the DNS zone information. This will cause the most replication because every Active Directory “enabled DNS server within the forest will hold the records for the zone, but the only domain controllers that will receive the data will be those that host the DNS service. You cannot have any Windows 2000 “based domain controllers in this scenario.
The second option ”replicating to all DNS servers within the domain ”will reduce the amount of replication traffic because only the domain controllers that are DNS servers for the domain in question will hold a copy of the domain records. Again, as with the previous option, you cannot have any Windows 2000 “based domain controllers within the domain.
The third option ”replicating to all domain controllers within the domain ”essentially makes all of your domain controllers within the domain behave as if they are Windows 2000 domain controllers. Every domain controller, whether or not it is a DNS server, will hold the data for the zone. If you still have some Windows 2000 “based domain controllers that are DNS servers, this is the option you will choose.
 |
Andrew was designing the DNS zones for his organization. He had decided upon using a completely separate namespace internally than was used externally. To compound problems, he had two companies within his organization and he needed to be able to resolve both domain names from all clients.
The first company, Robotic Concepts, had an Internet presence that was seen by external clients as robocon.com. The second company was a consulting company, Robotic Specialists, whose Internet presence was roboticspecialists.com.
To control access to internal resources, Andrew had designed the network infrastructure to include a perimeter network with a DNS server that hosted records for the servers within the perimeter and acted as a DNS server for external resolution. The DNS server within the perimeter was configured with root hints that pointed to the root DNS servers on the Internet.
Internally, Andrew configured a DNS server to be authoritative for the domain lcl. The DNS server did not host any root hints but did have a forwarder to the DNS server within the perimeter network. Within the .lcl zone, Andrew configured a delegation record for robocon.lcl and robospecs.lcl. He then created the zones for each of the domains and configured them for secure and nonsecure updates.
| |
The final option ”replicating to all domain controllers defined in the replication scope of a DNS application directory partition ”is also an option that is only available to Windows Server 2003 domain controllers. Using an application directory partition, you can choose which of the domain controllers will host a copy of the partition. In this manner, you can control exactly which domain controllers that are also DNS servers will host the zone data. If you do not want to replicate the zone to a server that is across a WAN, you will not have to.
Identifying Migration Options
As with everything else, Microsoft wants you to leave third-party products and start using Windows-based solutions exclusively. You will find that Microsoft has included methods of easy migration from third-party services. With DNS, you can use two methods to migrate existing zones to the Windows Server 2003 DNS service: using a zone transfer and copying the zone file.
If you use a zone transfer, you can configure the Windows Server 2003 server with a secondary zone and choose the third-party DNS server s zone as the master. Once configured, you can initiate a zone transfer from the master zone to the secondary. This should populate the Windows Server 2003 DNS server with all of the records. Once the transfer has completed, you can decommission the original DNS server and change the secondary zone to a primary zone. Make sure that the SOA record reflects the correct server as the authoritative server.
The second method requires you to copy the zone files that are used by the third-party DNS server onto your Windows Server 2003 DNS server. Using this method, you could decommission the third-party system and put the Windows Server 2003 system in its place, using the same hostname and IP address. Before copying the file, you should always make sure that the data within the zone is correct and does not have any erroneous data.
Make sure that your migration to Windows Server 2003 does not alienate any of your users. Create a schedule for migrating and upgrading your servers so that the users will still have access to the existing DNS server while the server you are upgrading is offline. Once the upgrade has been completed, make sure you test the server prior to upgrading any other servers that the users are currently utilizing .
Identifying Delegation Options
In large organizations or organizations that have several locations hosting many users and servers, you may want to delegate the administrative responsibilities to administrators at each location. You can delegate the administration of the DNS zones by creating delegation records or stub zones within your DNS infrastructure that point to name servers that are authoritative for the subdomain.
The two methods of creating references to the subdomain are to create a delegation record , which is a resource record that identifies a server that is authoritative for the subdomain, or to create a stub zone that will hold the zone SOA, NS, and A records for the name servers. If you have a DNS infrastructure that supports the use of stub zones, you should seriously consider using them because the stub zone will automatically update and you will not be required to manually update as you would with a delegation record.
| |
Celia is the Windows administrator for an organization that has a large existing UNIX infrastructure. The organization has decided to move to Active Directory, and now it is Celia s responsibility to make sure that all of the systems she is putting in place will interoperate with the existing systems. The current DNS administrators have decided that they will not relinquish any control over the DNS infrastructure. Currently they run BIND 9.1.0. Celia wants to take advantage of Active Directory “integrated zones, so she knows that she will have to use a Windows DNS server. The meetings that follow are not very fruitful because the existing DNS administrators are being adamant that they will not have a Windows-based DNS server in the organization.
Finally Celia reached a compromise with the DNS administrators. Because her DNS servers will all be Active Directory “integrated, she will concede to using a subdomain within the existing namespace that the organization is using internally. Her group will be responsible for maintaining the Active Directory domain. To maintain name resolution within the entire organization for all services, the existing BIND servers will host a stub zone pointing to the new subdomain.
| |
If your organization is already using a BIND DNS solution, and the administrators of the existing DNS infrastructure are leery of a Windows-based DNS solution, you can still use a Windows-based DNS to host your Active Directory integrated zones, and the current BIND administrators, if the BIND servers are running BIND 9 or later, can create stub zones that point to your zone. If the BIND servers are releases prior to 9 or a NetWare or Windows NT 4 solution is in place, you will have to create delegation records pointing to the new Active Directory zones.
The section that follows describes the options you have for implementing a name resolution infrastructure. Make sure you fully understand the options we have discussed up to this point before going on. Otherwise, you may find yourself designing an inefficient solution for your organization.
EAN: 2147483647
Pages: 159