Lesson 1: Designing DNS Security | MCSE Training Kit (Exam 70-220): Designing Microsoft Windows 2000 Network Security: Designing Microsoft(r) Windows(r) 2000 Network Security (IT-Training Kits)

Deploying Domain Name System (DNS) service is one of the key steps in designing your Active Directory. DNS acts as the locator service in a Windows 2000 network. When designing a DNS deployment, ensure that security is maintained so that the DNS Service doesn't expose excessive information about the internal network.

After this lesson, you will be able to

Design security for your DNS deployment

Estimated lesson time: 45 minutes

Assessing Security Risks for the DNS Service

DNS gives you the ability to resolve host names to IP addresses on a Transmission Control Protocol/Internet Protocol (TCP/IP) network. DNS is the standard resolution service that the Internet uses for addressing and resolving Internet-based resources. Within a Windows 2000 network, DNS provides the locator service for Windows 2000 service through the implementation of Service (SRV) resource records as defined in RFC 2782, as well as standard DNS resource records such as Host (A), Canonical Name (CNAME), Mail Exchanger (MX), and Pointer (PTR) records.

Make sure that the DNS Service is properly configured so that client computers can easily query the DNS Service to resolve services and hosts to specific IP addresses on the network.

Determining Network Services with SRV Resource Records

The SRV resource records provide a mechanism for finding common services in a Windows 2000 network. The format of the SRV resource record is as follows:
 _ldap._tcp.microsoft.com. 600 SRV 0 100 389 dc1.microsoft.com 
The following components are defined in an SRV resource record:

_ldap._tcp.microsoft.com. This component refers to three separate pieces of information:

The advertised service (_ldap). Valid options for Windows 2000 services include _ldap (the Lightweight Directory Access Protocol [LDAP] service), _Kerberos (the Kerberos Key Distribution Center), _gc (Windows 2000 global catalog servers), and _pdc (Windows 2000 primary domain controller emulators).

The transport protocol (_tcp). Each protocol uses either transmission control protocol (TCP) or user datagram protocol (UDP).

The domain (microsoft.com). In this case the LDAP service will be able to resolve LDAP queries for the microsoft.com domain.

The time to live (TTL) (600). This is the amount of time (in seconds) that the SRV resource record will be cached at a DNS server or DNS client in the resolver cache.

SRV. This indicates that the resource record is a service resource record indicating the location of a network service on the network.

The priority and weight (0 100). The combination of these two fields allows you to configure preference for one SRV resource record over another SRV resource record for the duplicate service.

The port that the service is listening on. In this case the LDAP service listens on TCP port 389.

Network host where the LDAP service resides (dc1.microsoft.com). In this case the LDAP service is hosted on dc1.microsoft.com. During the resolution process this host name would be resolved by querying DNS for the A resource record.

Since DNS can reveal the internal structure of your network to a potential attacker, security within your DNS infrastructure is an important design consideration. The potential risks of deploying the DNS Service with inadequate security include the following:

Dynamic update can allow client computers to overwrite existing DNS resource records and hijack sessions.
Without adequate security, an attacker can create a secondary DNS zone and obtain a read-only copy of your DNS zone data, which will reveal all resource records located within the source zone.
DNS services available on the Internet could expose the internal IP addressing scheme of the internal network.

Securing Dynamic Updates

The DNS Service in Windows 2000 provides security through a new zone type known as an Active Directory-integrated zone. Active Directory–integrated zones store their resource records within Active Directory instead of standard DNS text files. When the data is stored in Active Directory, each resource record exists as an object in Active Directory and has a Discretionary Access Control List (DACL) that limits which computers can update the resource record.

Deploying Active Directory–integrated zones offers the following advantages:

Fault tolerance of zone data. The DNS zone data can be shared between DCs in the same domain. If the DC has the DNS Service installed, you can query the DC for DNS resolution and read the resource records from Active Directory.
Reduction in replication topologies. Rather than having to configure a standard DNS deployment involving zone transfers between master servers and secondary servers, Active Directory–integrated zones transfer their data using the existing Active Directory replication methods.
Security on resource records. Because the resource records are stored in Active Directory, the resource records are treated as objects with DACLs that will protect the resource records. Only the resource record's owner can modify the resource record. To enable this feature, set the dynamic update option to only allow secure updates.

NOTE
Many networks implement Berkeley Internet Name Daemon (BIND) DNS servers for their DNS service. BIND 8.x DNS can restrict only dynamic updates to specific IP addresses. The BIND DNS Service doesn't have a mechanism to provide authenticated DNS updates using Active Directory authentication.

Restricting Zone Transfers

Zone transfers are used to transfer zone data to secondary DNS servers. The zone transfer ensures that any secondary DNS servers have current information for all resource records in the zone.

NOTE
Active Directory–integrated zones are limited to a single domain. If you need to have zone data available in multiple domains, you must still implement secondary DNS zones.

You can secure the zone transfer process by restricting zone transfers to approved DNS servers, as shown in Figure 9.2.

Figure 9.2 Restricting DNS zone transfers to authorized DNS servers

By restricting the DNS servers that can act as secondary DNS servers for your source zone, you ensure that only authorized DNS servers can perform zone transfers of the data.

WARNING
A common method for acquiring all zone data from a DNS server is to use the command LS _d DOMAIN.COM within the NSLOOKUP command to cause a zone transfer. If you restrict zone transfers to specific DNS servers, attackers will fail to acquire the zone data if they run the LS _d DOMAIN.COM command.

Implementing Separate External DNS Servers

If your organization is hosting its DNS services on the Internet, the DNS server that processes requests from the Internet should be different from the DNS server used internally. Using separate DNS servers allows you to exclude all internal DNS resource records from the external DNS server and prevent an attacker from determining the internal addressing scheme, as shown in Figure 9.3.

click to view at full size.

Figure 9.3 Ensuring that the external DNS server contains only externally available resource records

NOTE
Implementing separate internal and external DNS servers might require you to include external resource records in the internal DNS zone. You need to do this when the Active Directory forest root uses the same DNS domain name as the external network. In this situation you can't use forwarders to resolve the external DNS resource records because the internal DNS zone is authoritative for the DNS zone. If the resource record isn't found in an authoritative zone, DNS will report that the resource record doesn't exist and the DNS request won't be forwarded to the configured forwarder.

Restricting Membership in the DNS Admins Group

The DNS Admins group is assigned the right to create new DNS zones at a DNS server and to modify the properties of a DNS server. Only authorized user accounts should be members of the DNS Admins group. By using Restricted Groups in Group Policy, you can restrict DNS Admins group membership.

Making the Decision

Table 9.3 reviews the design decisions that you face when securing the DNS Service and the actions that you must perform.

Table 9.3 Securing the DNS Service

To	Do the Following
Protect the internal address space	Deploy separate DNS services for the internal and the external network. The external DNS server should never have internal resource records in the zone.
Prevent the failure of a single server from stopping dynamic DNS updates	Design the DNS zones as Active Directory–integrated DNS zones.
Prevent unauthorized DNS servers from hosting your DNS zone data	Configure zone transfers to take place only to authorized servers.
Prevent registration of unauthorized resource records	Use Active Directory–integrated zones. When using a BIND DNS server, restrict by IP address.
Prevent unauthorized membership in the DNS Admins group	Define the membership in the Restricted Groups Group Policy setting to include only authorized members.

Applying the Decision

To secure the DNS service, Lucerne Publishing needs to include the following components in its network security design:

Establish both internal and external DNS servers to host the lucernepublishing.tld domain. Because lucernepublishing.tld is used both on the Internet and as the Active Directory forest root, the DNS zone must be provided on both an external and an internal DNS server. Using two servers will ensure that the SRV resource records and internal addressing information in the lucernepublishing.tld domain aren't exposed on the Internet.
Configure secondary DNS servers for the lucernepublishing.tld zone on DNS servers in each of the child domains. The lucernepublishing.tld DNS zone is an Active Directory–integrated zone. Active Directory–integrated zones can be replicated only between DCs in the same domain. To provide access to the lucernepublishing.tld domain at each of the cities, configure a DNS server at each city as a secondary DNS server for the lucernepublishing.tld zone.
Restrict zone transfers to approved secondary DNS servers. To ensure that only approved secondary DNS servers are able to perform zone transfers with the lucernepublishing.tld DNS zone, restrict zone transfers for the zone to the IP address of the DNS servers in the child domains. In addition, configure each secondary DNS server not to allow DNS zone transfers.

Lesson Summary

The DNS service is required for Windows 2000 Active Directory. Consider the security implications of the DNS service when you design your DNS zones. Use Active Directory–integrated zones to ensure that the owner of a DNS resource record is the only one who can update the resource record.