- Introduction
- Introduction to DNS
- Planning a DNS Namespace Design
- Planning DNS Zone Requirements
- Planning DNS Forwarding Requirements
- Configuring DNS Security
- Integrating with Third-Party DNS Solutions
- Introduction to WINS
- Implementing WINS Replication
- Implementing NetBIOS Name Resolution
- Troubleshooting Name Resolution Problems
- Chapter Summary
- Apply Your Knowledge
This chapter is from the book
This chapter is from the book
This chapter is from the book
Planning DNS Zone Requirements
Plan a host name resolution strategy.
- Plan zone replication requirements.
You can easily get lost in the maze of acronyms and buzzwords surrounding DNS, especially if you are having a conversation with someone who has been working with IP networking and DNS for a while. You have a standard primary server for each zone, which might also be a domain, unless it's a reverse lookup zone; then you have zone transfers happening when you least expect it. To the uninitiated, this discussion can sound alarmingly like some arcane networking ritual, paying homage to the DNS deities.
Working with DNS is not nearly as bad as it sounds. But before we get any deeper into the Windows Server 2003 DNS infrastructure, we must discuss what exactly is meant when we refer to a DNS zone. First, although it is typically abbreviated in the world of DNS, a zone is actually a zone of authority, which means that it contains the complete information on some part of a domain namespace. In other words, it is a subset or root of that portion of namespace. The nameserver is considered to have authority for that zone, and it can respond to any requests for name resolution from that zone. So, when you look at the DNS name http://www.quepublishing.com, quepublishing.com is a DNS zone within the .com hierarchy. The www denotes the DNS record of a host contained within the quepublishing.com zone.
This conceptual representation of a zone also has a physical counterpart: All the information relating to a particular zone is stored in a physical file known as the zone database file, or more commonly the zone file, that can be found at %systemroot%\system32\dns for zones that are not stored in Active Directory. The following types of zones are supported by Windows Server 2003:
Standard primary—A standard primary zone holds a master copy of a zone and can replicate it to all configured secondary zones in standard text format. Any changes that must be made to the zone are made on the copy stored on the primary.
Standard secondary—A standard secondary zone holds a read-only copy of the zone information in standard text format. Secondary zones are created to increase performance and resilience of the DNS configuration. Information is transferred from the primary zone to the secondary zones.
Active Directory–integrated—Active Directory–integrated zones are available only on Windows 2000 Server and Windows Server 2003 DNS servers in an Active Directory domain. The zone information is contained within the Active Directory database and is replicated using Active Directory replication. Active Directory–integrated zones provide an increased level of replication flexibility as well as security. Active Directory–integrated zones also operate in a multimaster arrangement because they are hosted within Active Directory itself; this way, any DNS server (domain controller) hosting the Active Directory–integrated zone can update the zone data.
Stub—Microsoft has introduced support for stub zones for the first time in Windows Server 2003. A stub zone contains only those resource records that are necessary to identify the authoritative DNS servers for that zone. Those resource records include Name Server (NS), Start of Authority (SOA), and possibly glue host (A) records. (Glue host records provide A record pointers to ensure that the master zone has the correct nameserver information for the stub zone.)
NOTE
"What's the difference between a zone and a domain?" Although the two terms can seem as if they are used interchangeably, there is a difference. A DNS domain is a segment of the DNS namespace. A zone, on the other hand, can contain multiple contiguous domains.
For example, quepublishing.com is a DNS domain. It contains all the information for that specific portion of the DNS namespace. sales. quepublishing.com is another example of a domain, which is contiguous with the quepublishing.com domain; in other words, the two domains "touch." So, if you were to create a DNS forward lookup zone on your DNS server, it could contain records for both domains. Zones allow for the logical grouping and management of domains and resource records on your DNS servers.
Although determining the zone type might not seem to be an important part of planning your DNS solution, nothing could be further from the truth. The type of DNS zone that you implement ultimately determines the placement of the DNS servers in your network. In addition, the type of DNS zone that you create will, in part, affect the construction of the network and the interoperability with other DNS servers, such as Unix Berkeley Internet Name Domain (BIND) servers.
When you are using a standard primary/standard secondary DNS zone implementation, the following points are of concern:
A single DNS server is the master, holding the only writable copy of the DNS zone file.
Zone transfers can be conducted using either incremental or full zone transfer.
This implementation is fully compatible with BIND DNS servers by using the standard DNS zone transfer methods in place.
When you are using an Active Directory–integrated DNS zone implementation, the following points are of concern:
A multimaster arrangement allows any DNS server to make updates to the zone file.
Zone data is replicated with Active Directory data.
Increased security is provided on the zone file.
Redundancy is provided for DNS dynamic update.
The administrator can adjust replication scope. Additionally, the zone file can be replicated to a standard secondary DNS server—a common practice for DNS servers placed on screened subnets.
This implementation appears to be a standard primary zone to a BIND DNS server, thus allowing the use of BIND DNS servers as standard secondary zone servers.
Table 3.2 provides a comparison of Active Directory–integrated zones and standard DNS zones.
Table 3.2 DNS Zone Type Comparison
|
DNS Feature |
Standard DNS Zones |
Active Directory–Integrated Zones |
|
Complies with Internet Engineering Task Force (IETF) specifications |
Yes |
Yes |
|
Uses Active Directory for replication |
No |
Yes |
|
Increases availability by providing a multimaster arrangement |
No |
Yes |
|
Allows for zone updates after the failure of a single DNS server |
No |
Yes |
|
Supports incremental zone transfers |
Yes |
Yes |
Regardless of whether you create standard or Active Directory– integrated DNS zones, you should be aware of the benefits of also using standard secondary zones. The following list presents some of the benefits you can realize by placing secondary zones on your network:
The addition of standard secondary zone servers increases the redundancy of the zone by proving name resolution even if the primary zone server is unresponsive.
When remote locations are connected to the core network over WAN links, secondary zone servers can greatly reduce costs and network traffic. By placing standard secondary zones in these remote locations or in locations with a high number of clients, you can improve overall network performance.
Standard secondary zone servers reduce the load on the primary servers by distributing name resolution requests among more DNS servers.
NOTE
Keeping zones safe If you are using standard zones, or a secondary zone within an Active Directory–integrated zone implementation, you must ensure that you configure your DNS servers to perform zone transfers only with those servers you trust.
At this point, you have a fair amount of information in hand to start planning your DNS zone requirements. Depending on what types of zones you implement, your zones will use either transfers or replication. Zone transfers occur in standard zones, whereas zone replication occurs in Active Directory–integrated zones.
Unlike WINS, which allows for a push/pull arrangement, zone transfers always originate with the secondary server polling the primary zone at the configured interval. It does so by checking the zone version number on the primary server to see whether it has changed in comparison to the version number on the secondary server. As changes are made to the zone file, the zone version number is incremented. When the zone version number on the primary server has been incremented, a zone transfer is required and will be performed. If the secondary zone supports incremental zone transfers (which Windows Server 2003 does), the secondary zone pulls (from the primary zone) only the changes made to resource records for each incremental zone version—meaning that a resource record could potentially be updated one or more times in a single zone transfer. When you use incremental zone transfers, network traffic is reduced and zone transfer speed is increased.
NOTE
Zone transfer types Windows Server 2003 supports two zone transfer types for standard zones: full zone transfers and incremental zone transfers. You might also see these transfers abbreviated as AXFR and IXFR, respectively. A full zone transfer causes the entire zone data file to be transferred, which is both a large user of bandwidth and time.
Active Directory–integrated DNS zones replicate data among all domain controllers, allowing any domain controller to modify the zone file and replicate the changes to the rest of the domain controllers that are running the DNS service. Replication occurs on a per-property basis, meaning that only the relevant changes will be replicated. Active Directory–integrated zones replicate only the final result of multiple changes to a resource record, unlike standard zones, which transfer the changes to a resource record that occurred in each zone version number.
With your namespace and zone type plans complete, you must next evaluate the need for forwarder and slave DNS servers. That is the topic of the next section.