Monitor DNS | ActiveXperts Network Monitor and Internet Protocols

DNS Fundamentals

The Domain Name System is a hierarchical distributed database and an associated set of protocols that define:

• A mechanism for querying and updating the database;
• A mechanism for replicating the information in the database among servers
• A schema of the database

History of DNS

DNS began in the early days of the Internet when the Internet was a small network established by the Department of Defense for research purposes. The host names of the computers in this network were managed through the use of a single HOSTS file located on a centrally administered server. Each site that needed to resolve host names on the network downloaded this file. As the number of hosts on the Internet grew, the traffic generated by the update process increased, as well as the size of the HOSTS file. The need for a new system, which would offer features such as scalability, decentralized administration, support for various data types, became more and more obvious. The Domain Name System (DNS) introduced in 1984, became this new system. With DNS, the host names reside in a database that can be distributed among multiple servers, decreasing the load on any one server and providing the ability to administer this naming system on a per-partition basis. DNS supports hierarchical names and allows registration of various data types in addition to host name to IP address mapping used in HOSTS files. By virtue of the DNS database being distributed, its size is unlimited and performance does not degrade much when adding more servers. The original DNS was based on RFC 882 (Domain names: Concepts and facilities) and RFC 883 (Domain Names-Implementation and Specification), which were superceded by RFC 1034 (Domain Names-Concepts and Facilities), and RFC 1035 (Domain Names-Implementation and Specification). RFCs that describe DNS security, implementation, and administrative issues later augmented these. The implementation of DNS-Berkeley Internet Name Domain (BIND)-was originally developed for the 4.3 BSD UNIX operating system. The Microsoft implementation of DNS Server became a part of the operating system in Windows NT Server 4.0. The Windows NT 4.0 DNS Server, like most DNS implementations, has its roots in RFCs 1034 and 1035. The latest version of the Windows 2000 operating system includes a new version of DNS. The RFCs used in this version are 1034, 1035, 1886, 1996, 1995, 2136, 2308 and 2052.

The Structure of DNS

The Domain Name System is implemented as a hierarchical and distributed database containing various types of data including host names and domain names.
The names in a DNS database form a hierarchical tree structure called the domain name space.

The Hierarchy of DNS: Domain Names

Domain names consist of individual labels separated by dots. For example: mydomain.microsoft.com. A Fully Qualified Domain Name (FQDN) uniquely identifies the host's position within the DNS hierarchical tree by specifying a list of names separated by dots on the path from the referenced host to the root. The following figure shows an example of a DNS tree with a host called mydomain within the microsoft.com. domain. The FQDN for the host would be mydomain.microsoft.com.

DNS and Internet

The Internet Domain Name System is managed by a Name Registration Authority on the Internet, responsible for maintaining top-level domains that are assigned by organization and by country. These domain names follow the International Standard 3166. Existing abbreviations, reserved for use by organizations, as well as two-letter and three-letter abbreviations used for countries, are shown in the following table.

Distributing the Database: Zone Files and Delegation

Distributing the Database: Zone Files and Delegation A DNS database can be partitioned into multiple zones. A zone is a portion of the DNS database that contains the resource records with the owner names that belong to the contiguous portion of the DNS namespace. Zone files are maintained on DNS servers. A single DNS server can be configured to host zero, one or multiple zones. Each zone is anchored at a specific domain name referred to as the zone's root domain. A zone contains information about all names that end with the zone's root domain name. A DNS server is considered authoritative for a name if it loads the zone containing that name. The first record in any zone file is a Start of Authority (SOA) RR. The SOA RR identifies a primary DNS name server for the zone as the best source of information for the data within that zone and as an entity processing the updates for the zone. Names within a zone can also be delegated to other zone(s). Delegation is a process of assigning responsibility for a portion of a DNS namespace to a separate entity. This separate entity could be another organization, department or workgroup within your company. In technical terms, delegating means assigning authority over portions of your DNS namespace to other zones. Such delegation is represented by the NS record that specifies the delegated zone and the DNS name of the server authoritative for that zone. Delegating across multiple zones was part of the original design goal of DNS. Following are the main reasons for the delegation of a DNS namespace:

• A need to delegate management of a DNS domain to a number of organizations or departments within an organization;
• A need to distribute the load of maintaining one large DNS database among multiple name servers to improve the name resolution performance as well as create a DNS fault tolerant environment;
• A need to allow for host's organizational affiliation by including them in appropriate domains.

The NS RRs facilitate delegation by identifying DNS servers for each zone. They appear in all forward and reverse look-up zones. Whenever a DNS server needs to cross a delegation, it will refer to the NS RRs for DNS servers in the target zone.

Replicating the DNS database

There could be multiple zones representing the same portion of the namespace. Among these zones there are two types:

• Primary;
• Secondary

Primary is a zone to which all updates for the records that belong to that zone are made. A secondary zone is represented by a read-only copy of the primary zone. The changes made to the primary zone file are then replicated to the secondary zone file. As mentioned above, a name server can host multiple zones. A server can therefore be primary for one zone (it has the master copy of the zone file) and secondary for another zone (it gets a read-only copy of the zone file). The process of replicating a zone file to multiple name servers is called zone transfer. Zone transfer is achieved by copying the zone file information from the master server to the secondary server. A master server is the source of the zone information. The master server can be primary or secondary. If the master is primary, then the zone transfer comes directly from the source. If the master server is secondary, the file received from the master server by means of a zone transfer is a copy of the read-only zone file. The zone transfer is initiated in one of the following ways:

• The master server sends a notification (RFC 1996) to the secondary server(s) of a change in the zone;
• When the secondary server's DNS service starts or the secondary server's refresh interval has expired (by default it is set to 15 minutes in the SOA RR), it will query the primary server for the changes.

There are two types of zone file replication. The first, full zone transfer (AXFR), replicates the entire zone file. The second, incremental zone transfer (IXFR), replicates only the changed records of the zone. The IXFR protocol is discussed in "Incremental Zone Transfer." BIND 4.9.3 DNS servers, as well as Windows NT 4.0 DNS, support full zone transfer (AXFR) only. There are two types of the AXFR: one requires single record per packet, the other allows multiple records per packet. The Windows 2000 DNS server supports both, but by default uses multiple records per packet, unless is configured differently for compatibility with BIND versions 4.9.4 and earlier, that do not allow multiple records per packet. The Windows 2000 DNS server supports incremental zone transfer (IXFR).

Querying the Database

DNS queries can be sent from a client (resolver) to a DNS server (a name server), or between two name servers. A query is merely a request for records of a specified type with a specified name. For example, a query can request all host RRs with a particular name. There are two types of queries that can be made to a DNS server:

• Recursive
• Iterative

A recursive query forces a DNS server to respond to a request with either a failure or a successful response. Resolvers typically make recursive queries. With a recursive query, the DNS server must contact any other DNS servers it needs to resolve the request. When it receives a successful response from the other DNS Server(s), it then sends a response to the client. The recursive query is typical for a resolver querying a name server and for a name server querying its forwarder (another name server configured to handle requests forwarded to it). When a DNS server processes a recursive query and a query can not be resolved from local zone files, the query must be escalated to a root DNS server. Each standards-based implementation of DNS includes a cache file (or root server hints) that contains entries for Root Servers of the Internet domains. The latest version of the named cache file can be downloaded from InterNIC at ftp://rs.internic.net/domain/named.cache. An iterative query is one in which the name server is expected to provide the best information (also known as referral if the server is not authoritative for the name) based on what the server knows from local zone files or from caching. If a name server doesn't have any information to answer the query, it simply sends a negative response. A non-forwarding DNS server makes this type of query as it tries to find names outside its local domain(s). It may have to query a number of outside DNS Servers in an attempt to resolve the name.

Time to Live for Resource Records

A resolver caches the information it receives when it resolves queries. These cached responses can then be used to answer subsequent queries for the same information. The cached data, however, has a limited lifetime specified in the Time To Live (TTL) parameter returned with the data. TTL makes sure the DNS Server doesn't keep information for so long that it becomes out of date. TTL for the cache can be set on the DNS database (per individual RR by specifying the TTL field of the record and per zone through the minimum TTL field of the SOA record) as well as on the resolver side by specifying the maximum TTL the resolver allows to cache the resource records. There are two competing factors to consider when setting the time to live. One is the accuracy of the cached information, the other is the DNS server's utilization and the network traffic. If the TTL is short, then the likelihood of having old information goes down considerably, but increases the DNS servers utilization and the network traffic. If the TTL is long, the cached responses could become outdated, meaning the resolver could give false answers to queries. At the same time a long TTL decreases the DNS server's utilization and the network traffic. If a query is answered with an entry from cache, the TTL of the entry is also passed with the response. This way the resolvers that receive the response know how long the entry is valid. The resolvers honor the TTL from the responding server; they don't set it again based on their own TTL. Thus entries truly expire rather than live in perpetuity as they move from server to server with an updated TTL.