The Domain Name System (DNS) is a static hierarchical name resolution architecture that relies on client/server communication for operation. DNS is a protocol that many use every day and may not know it. Whenever someone browses the Internet, DNS is used in the background to translate host names into IP addresses so that the proper network destinations can be found. DNS is equally important in VoIP networks for its ability to resolve destination endpoint addresses or allow gateway registration to call servers and gatekeepers by host name.
DNS was created so that no one would be required to memorize the IP addresses of every host on a private network or the Internet. Most people have a hard enough time remembering one or two passwords, let alone several billion IP addresses. With the development of DNS, the only requirement is knowledge of the target Web page name that you wish to go to. DNS resolves the target Web page name entered into one or more server IP addresses. It has also been designed to allow the reverse or “inverse” resolution of IP addresses to host names.
The DNS architecture was first discussed in detail in RFCs 881 through 883, and later updated in RFCs 1034 and 1035. Several of the newer RFCs include recommendations for how to secure the DNS architecture, including the addition of DNS security extensions (DNSSEC) beginning with RFC 4033. The next few sections detail a high-level overview of the DNS architecture and several security threats associated with DNS systems.
DNS Architecture
In order to better understand and be able to address the security concerns associated with DNS properly, it is important to have at least a high-level understanding of how DNS works. The hierarchy previously mentioned for DNS exists as a pyramid, with the highest level of the DNS architecture at the top. DNS is organized into myriad logical groupings called domains, which are further segmented into an endless number of subdomains. Figure 1 illustrates a sample hierarchy of the DNS system and is by no means exhaustive. The intent is to show the structure of the hierarchy.
Located at the top of the DNS hierarchy are the root DNS servers. The root DNS servers are located in the root DNS zone, annotated by a single “.”, and are responsible for maintaining the location of the top-level domain servers (TLD). ATLD DNS server is one that is responsible for the management of one of the commonly associated address suffix identifiers, such as .com, .net, .edu, or .org. The TLD DNS servers are assigned or “dele-gated” the responsibility by the root DNS servers. They are known as the authoritative server for that TLD. Likewise, the TLD DNS servers delegate the management of one of their many subdomains. The subdomain DNS servers for .brad.com would be responsible for any resource records (RR) for that subdomain as well as the location of any related subdomains (.hr.brad.com). The resource records are the entries for the host systems. This process of delegation distributes the load of the DNS system across many different servers.
Fully Qualified Domain Name
Each host has its own pointer for DNS, known as a fully qualified domain name (FQDN). The FQDN is used to identify the path taken through the DNS architecture to find the requested host. Figure 2 illustrates what path is taken through the previously discussed DNS hierarchy from Figure 1 to reach host pc1.
There are a couple of things to keep in mind about FQDNs. First of all, the explicit FQDN path from the top of the hierarchy (root) is read from right to left. Secondly, even though most FQDN illustrations do not include the final dot to represent the root domain, it is an implied part of the complete FQDN. Most applications, like IE, will not append a trailing “.” to the end of a requested Web resource. Followed from right to left, the host pc1 follows a path out of the root domain, through the TLD .com, to the .com subdomain .brad.com, and then finally into the .brad.com subdomain of .hr.brad.com.
FQDNs are entered into the DNS tables as one of several types of RRs:
- A An A record is an address record, denoting a standard host entry in the DNS table. The key here is that it is used to resolve an FQDN to an IP address.
- PTR PTR records are used by the inverse lookup zones in DNS. The PTR record resolves an IP address to an FQDN.
- SOA The SOA record identifies zone information such as the zone name and serial number.
- NS NS records are used for name servers for the zone.
- CNAME CNAME records act as alias records to allow for the translation of one host name into another.
- INFO Provides information about hosts listed in the DNS table.
- SRV SRV records identify SIP servers for the zone.
DNS Client Operation
In order to locate the IP address for a host, the client’s application will send a request to a resolver on the same client system. The resolver will then formulate and send out the DNS query. From a high level, the query will typically follow a path of trial and error known as a recursive lookup. Figure 3 illustrates what a recursive lookup from a host, pc2, would look like to find the IP address for host pc1.
- The client’s resolver sends its DNS query which will be sent to the root domain.
- The root domain server does not have the RR for the host pc1, so the response is sent to redirect the resolver on pc2 to the TLD DNS server for .com since it knows where .com. is.
- The TLD DNS server does not have the RR for the host pc1, so the response is sent to redirect the resolver on pc2 to the .brad.com. DNS server since it knows where .brad.com. is.
- The resolver, in turn, sends a query to the DNS server for .brad.com.
- The .brad.com. DNS server does not have the RR for the host pc1, so the response is sent to redirect the resolver on pc2 to the .hr.brad.com. DNS server since it knows where .hr.brad.com. is.
- The resolver, in turn, sends a query to the DNS server for .hr.brad.com.
- The authoritative DNS server for .hr.brad.com. has the RR for the host pc1 and sends back the information to pc2. pc2 now has the IP address information for pc1, and may use it accordingly.
| Note |
It is not required to have a separate DNS server for each subdomain. A single DNS server may be the authoritative server for many, or all, of the subdomains in a corporation, although there are usually backup DNS servers configured for each primary DNS server.
|
DNS Server Operation
The DNS server is responsible for cataloging all of the RRs that belong to any of the zones that it is the authoritative DNS server for. It is also responsible for keeping track of any of the DNS servers that it has delegated subdomain responsibility to. By keeping track of the subdomains, the DNS server is able to redirect client queries to the proper location in the event that the requested host RR does not reside on that server.
DNS servers may also be configured to maintain a cache of domain names, as well as their respective IP addresses, as they are requested by clients. This configuration allows a DNS server to retrieve an IP address only once and then store the value for any subsequent queries by the same client or any other client. These entries are cached for only a short period of time, equal to the Time To Live (ttl) value applied to the record. When a client requests a particular domain name resolution, the DNS server will first attempt to find the records in its local database. If this search fails, the DNS server will attempt to contact a root name server, if it’s been configured to do so, to request the value.
Another important function that the DNS servers provide is the replication of the DNS table, also known as a zone transfer. The zone transfer insures that all entries for a given zone will be available on all DNS servers in that zone. This is necessary so that DNS can provide a resilient operating architecture. Two types of zone transfers can be found between DNS servers: full and incremental. A full zone transfer is exactly as it sounds, a complete transfer of zone information between DNS servers. An incremental zone transfer, on the other hand, is one where only changed zone information is exchanged between DNS servers. Incremental zone transfers make more efficient use of bandwidth and network resources, but not all DNS server vendors support the newer implementation.
Zone transfers are based on several items, including serial numbers and refresh intervals. The secondary DNS server will request a zone transfer from the primary DNS server and there is a serial number embedded in the response. If the secondary server receives the response and the serial number is lower than or equal to the serial number of its current table version, the response will not be used to update the server’s table. However, if the serial number is higher, the DNS table will be updated to what is enclosed in the response.
The refresh interval is used to identify how often the secondary server should request a zone transfer from the primary server. It is used as a polling mechanism to help ensure that the secondary server remains up-to-date with the current DNS information. NOTIFY messages may also be used by the primary DNS server to tell the secondary DNS servers when changes have been made to the DNS table. When the secondary DNS server receives the NOTIFY, they can request a zone transfer to ensure table synchronization.
Security Implications for DNS
DNS is a core component of modern networking, and as such, is a rather attractive target for many attackers. When the DNS architecture was developed, security was not included as part of the design. There was nothing designed into the architecture for peer authentication, origin authentication, or data encryption. Some recent advancements in DNS have helped to alleviate some of the current security concerns, but they have not been able to remove them altogether.
The dangers of DNS are well publicized and well documented, owing to its long life on the Internet. More information on these security threats, how they are performed, and how to protect your DNS servers can be found at www.dnssec.net/dns-threats.php. There is also an RFC on DNS Threats, published as RFC 3833. Several types of attacks should be kept in mind regarding your DNS deployment, and some best practices can be employed to help lessen your exposure:
- DNS footprinting (using DNS zone data to learn host names, subdomains, and subnets)
- Denial of Service (DoS)
- SYN flooding of DNS server
- Transfer of blank DNS table
- DNS cache poisoning
1 comment:
thank you for the post , visit us for
best telephone solution for business
Post a Comment