DNS and Active Directory
**
Active Directory and the Domain Name System (DNS)
What is DNS? One can define the domain name system as the way that Internet domain names are located and translated into Internet Protocol addresses. A domain name is a meaningful and easy-to-remember "handle" for an Internet address.
Active Directory relies heavily on DNS to function, but not just any DNS. Active Directory is highly dependent on the Microsoft DNS service found on Windows 2000 Server or Windows Server 2003 systems or equivalents. However, though not highly recommended, it is possible integrate a non-Microsoft DNS to use with Active Directory.
Microsoft first introduced a DNS service with Windows NT Server 4.0. However, that early version of DNS from Microsoft is not capable of supporting Active Directory. Windows NT Server 4.0 DNS lacks three specific features: Service Resource Records (SRV RR), Dynamic DNS (DDNS) and Incremental Zone Transfers (IXFR). Without these DNS features, Active Directory cannot function. Therfore, it is essential to understand how DNS works.
DNS is extremely important to all aspects of proper Active Directory operation. Any time a client makes a request for a domain service, it must find a domain controller to service that request, which is where DNS comes in to play.
There are two types of DNS queries: recursive and iterative. When a DNS client requests DNS information, it uses a recursive query to do so. (And for the purposes of this discussion, a DNS client is any computer requesting DNS information, even if that computer happens to be running a server operating system.) In a recursive query, the DNS client sends its query to the first DNS server that it has been configured for in its TCP/IP configuration. It then sits and waits for the server to return an answer. If the server returns a positive response, the client will then go to the IP address returned by the server.
If it's a negative response, the client will return some sort of "Page/Resource not found" error to the user. One thing that's important to note here is that configuring multiple DNS servers on a client will not cause the client to check with subsequent servers if the first one returns a negative response. The only time a client will go to its secondary DNS server is if the first one is unavailable. If the first DNS server queried returns a negative response, the client will not try any secondary servers and will accept that negative response as final.
Adhering to proper DNS settings and best practices is crucial to Active Directory processes, such as replication.
DNS server configuration
DNS is fairly simple and straightforward. As long as you follow the basic rules of configuration, DNS will give you few problems. However, there are certain complex configurations that are important to know about and remember when configuring DNS servers, which can allow administrators to get a better handle on options that can make a difference in DNS operation, logging and troubleshooting.
One of the first things to figure out when learning DNS in Active Directory is knowing if a property is that of the DNS server or a zone. Both are exposed in the DNS Management snap-in tool.
Here are a couple of ways to keep them straight:
Server properties are general properties that apply to the whole DNS environment, such as Forwarding, Name Servers, root hints and logging.
Zone properties are specific properties that vary with the zone, such as dynamic updates, zone type (AD, Standard Primary or Secondary) and replication type.
DNS structure and design
DNS architecture design is also very important. When designing the DNS structure, it is important to keep in mind certain principles and practices that will affect the overall name resolution performance in the network. DNS structures that are patched together or not well thought out will work, but they have pockets of failure that will affect Active Directory performance. That is why adherence to best practices in the DNS structure is extremely important in creating an efficient and productive Active Directory.
One key to designing DNS involves the use of Active Directory integrated zones (ADI). An ADI zone is a writeable copy of a forward lookup zone that is hosted on a domain controller. This is a requirement since the DNS records are all held in Active Directory, thus the DNS server needs access to the AD. Since each DC hosts a writeable copy of the DNS zone, clients (workstations, servers and other DCs) can register their DNS records on a domain controller hosting an ADI primary zone -- usually the DC that authenticated them -- rather than search the network to find a single DNS server (primary) that will add the client's host and resource records.
So how is a DNS structure using Active Directory integrated zones designed? ADI zones can only be hosted on DCs. However, many administrators want to put domain name servers in remote sites to provide better name-resolution performance and to decrease network traffic. That way, users don't have to go across the WAN to find a DNS server. However, an administrator may not want to put a DC in that location. Windows 2000 Server and Windows Server 2003 allow admins to put a standard secondary zone (read only) on a member server and use one of the ADI primary servers as the master.
The rule is that an ADI primary zone can only exist on a DC, but admins can have a standard secondary of that zone on a member server. Thus, clients can connect to their local DNS server whether it is hosting the ADI primary or the secondary. When a client (DC, member server or workstation) tries to register, however, it can only register on a DNS server hosting the ADI primary zone. If the client points to a server hosting a secondary, the client will simply receive a referral to one of the primaries to be registered.
Protecting DNS
DNS security is a major priority. Many of the functions and features of Active Directory use DNS to locate domain controllers, systems, services, clients, and other objects. It should be obvious that protecting DNS is almost as important as protecting Active Directory itself. Basically, if DNS fails, so does Active Directory. This, in turn, means that if DNS fails, an entire network may be disabled.
Providing protection for DNS as a means to provide additional protection for AD DCs is an essential part of establishing a truly secure networking environment. Protecting your DNS servers will require a multi-pronged approach. First and foremost, establish the same secure design, implementation and deployment procedures for your DNS servers as I've recommended for your AD DCs.
Next, consider implementing secured communications with DNS servers, monitor all network traffic, and re-evaluate the open ports on your firewall. By encrypting all communications between DNS servers and all DNS clients (which includes not just end user clients but also Active Directory DCs and member servers), it will minimize or eliminate the possibility of traffic interception and manipulation. One of the best ways to implement this is through IPSec, which is is a framework for a set of protocols for security at the network or packet processing layer of network communication.
Note: While the implementation of IPSec across all systems will likely cause a measurable decrease in the performance of network communications due to the overhead of encrypting and decrypting communications, many experts feel the increased security should more than compensate for the slight reduction in throughput.
It is also important to monitor all network traffic and re-evaluate the open ports on your firewall. By monitoring network traffic, admins should be able to determine when illegitimate or abnormal traffic patterns or content begin to enter their network.
Even with all recommended precautions in place, however, there is still a possibility of a malicious person gaining access to a DNS server. If that happens, admins must rely upon internal DNS security precautions, which include:
Secure dynamic updates
DNS resource record registration quotas
Delegate DNS administration
Use secured routing
Maintain a split DNS namespace
Disable recursion
Troubleshooting DNS
DNS troubleshooting is an absolutely vital process in Active Directory. It is important to keep DNS healthy and to know how to repair it when it breaks.
**
Active Directory and the Domain Name System (DNS)
What is DNS? One can define the domain name system as the way that Internet domain names are located and translated into Internet Protocol addresses. A domain name is a meaningful and easy-to-remember "handle" for an Internet address.
Active Directory relies heavily on DNS to function, but not just any DNS. Active Directory is highly dependent on the Microsoft DNS service found on Windows 2000 Server or Windows Server 2003 systems or equivalents. However, though not highly recommended, it is possible integrate a non-Microsoft DNS to use with Active Directory.
Microsoft first introduced a DNS service with Windows NT Server 4.0. However, that early version of DNS from Microsoft is not capable of supporting Active Directory. Windows NT Server 4.0 DNS lacks three specific features: Service Resource Records (SRV RR), Dynamic DNS (DDNS) and Incremental Zone Transfers (IXFR). Without these DNS features, Active Directory cannot function. Therfore, it is essential to understand how DNS works.
DNS is extremely important to all aspects of proper Active Directory operation. Any time a client makes a request for a domain service, it must find a domain controller to service that request, which is where DNS comes in to play.
There are two types of DNS queries: recursive and iterative. When a DNS client requests DNS information, it uses a recursive query to do so. (And for the purposes of this discussion, a DNS client is any computer requesting DNS information, even if that computer happens to be running a server operating system.) In a recursive query, the DNS client sends its query to the first DNS server that it has been configured for in its TCP/IP configuration. It then sits and waits for the server to return an answer. If the server returns a positive response, the client will then go to the IP address returned by the server.
If it's a negative response, the client will return some sort of "Page/Resource not found" error to the user. One thing that's important to note here is that configuring multiple DNS servers on a client will not cause the client to check with subsequent servers if the first one returns a negative response. The only time a client will go to its secondary DNS server is if the first one is unavailable. If the first DNS server queried returns a negative response, the client will not try any secondary servers and will accept that negative response as final.
Adhering to proper DNS settings and best practices is crucial to Active Directory processes, such as replication.
DNS server configuration
DNS is fairly simple and straightforward. As long as you follow the basic rules of configuration, DNS will give you few problems. However, there are certain complex configurations that are important to know about and remember when configuring DNS servers, which can allow administrators to get a better handle on options that can make a difference in DNS operation, logging and troubleshooting.
One of the first things to figure out when learning DNS in Active Directory is knowing if a property is that of the DNS server or a zone. Both are exposed in the DNS Management snap-in tool.
Here are a couple of ways to keep them straight:
Server properties are general properties that apply to the whole DNS environment, such as Forwarding, Name Servers, root hints and logging.
Zone properties are specific properties that vary with the zone, such as dynamic updates, zone type (AD, Standard Primary or Secondary) and replication type.
DNS structure and design
DNS architecture design is also very important. When designing the DNS structure, it is important to keep in mind certain principles and practices that will affect the overall name resolution performance in the network. DNS structures that are patched together or not well thought out will work, but they have pockets of failure that will affect Active Directory performance. That is why adherence to best practices in the DNS structure is extremely important in creating an efficient and productive Active Directory.
One key to designing DNS involves the use of Active Directory integrated zones (ADI). An ADI zone is a writeable copy of a forward lookup zone that is hosted on a domain controller. This is a requirement since the DNS records are all held in Active Directory, thus the DNS server needs access to the AD. Since each DC hosts a writeable copy of the DNS zone, clients (workstations, servers and other DCs) can register their DNS records on a domain controller hosting an ADI primary zone -- usually the DC that authenticated them -- rather than search the network to find a single DNS server (primary) that will add the client's host and resource records.
So how is a DNS structure using Active Directory integrated zones designed? ADI zones can only be hosted on DCs. However, many administrators want to put domain name servers in remote sites to provide better name-resolution performance and to decrease network traffic. That way, users don't have to go across the WAN to find a DNS server. However, an administrator may not want to put a DC in that location. Windows 2000 Server and Windows Server 2003 allow admins to put a standard secondary zone (read only) on a member server and use one of the ADI primary servers as the master.
The rule is that an ADI primary zone can only exist on a DC, but admins can have a standard secondary of that zone on a member server. Thus, clients can connect to their local DNS server whether it is hosting the ADI primary or the secondary. When a client (DC, member server or workstation) tries to register, however, it can only register on a DNS server hosting the ADI primary zone. If the client points to a server hosting a secondary, the client will simply receive a referral to one of the primaries to be registered.
Protecting DNS
DNS security is a major priority. Many of the functions and features of Active Directory use DNS to locate domain controllers, systems, services, clients, and other objects. It should be obvious that protecting DNS is almost as important as protecting Active Directory itself. Basically, if DNS fails, so does Active Directory. This, in turn, means that if DNS fails, an entire network may be disabled.
Providing protection for DNS as a means to provide additional protection for AD DCs is an essential part of establishing a truly secure networking environment. Protecting your DNS servers will require a multi-pronged approach. First and foremost, establish the same secure design, implementation and deployment procedures for your DNS servers as I've recommended for your AD DCs.
Next, consider implementing secured communications with DNS servers, monitor all network traffic, and re-evaluate the open ports on your firewall. By encrypting all communications between DNS servers and all DNS clients (which includes not just end user clients but also Active Directory DCs and member servers), it will minimize or eliminate the possibility of traffic interception and manipulation. One of the best ways to implement this is through IPSec, which is is a framework for a set of protocols for security at the network or packet processing layer of network communication.
Note: While the implementation of IPSec across all systems will likely cause a measurable decrease in the performance of network communications due to the overhead of encrypting and decrypting communications, many experts feel the increased security should more than compensate for the slight reduction in throughput.
It is also important to monitor all network traffic and re-evaluate the open ports on your firewall. By monitoring network traffic, admins should be able to determine when illegitimate or abnormal traffic patterns or content begin to enter their network.
Even with all recommended precautions in place, however, there is still a possibility of a malicious person gaining access to a DNS server. If that happens, admins must rely upon internal DNS security precautions, which include:
Secure dynamic updates
DNS resource record registration quotas
Delegate DNS administration
Use secured routing
Maintain a split DNS namespace
Disable recursion
Troubleshooting DNS
DNS troubleshooting is an absolutely vital process in Active Directory. It is important to keep DNS healthy and to know how to repair it when it breaks.
**
Comments