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
Estimated lesson time: 45 minutes
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:
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:
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.
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.
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.
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.
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.
Figure 9.3 Ensuring that the external DNS server contains only externally available resource records
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.
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.
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.|
To secure the DNS service, Lucerne Publishing needs to include the following components in its network security design:
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.