This article covers the basic functions of the Domain Name System (DNS) to provide name resolution services to clients.
How DNS Works
Domain Name System (DNS) is the default name resolution service used on the Internet respectively on TCP/IP based communication networks. DNS is part of the TCP/IP protocol suite. All TCP/IP network connections are, by default, configured with the IP address of at least one DNS server in order to perform name resolution on the network.
DNS originated in the early days of the Internet when the Internet was a small network. The host names of the computers in this network were managed through the use of a single, centrally managed HOSTS file. Each site that needed to resolve host names was forced to use 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, scaleable and decentralized system became more and more obvious.
The Domain Name System 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. Because the DNS database is distributed, its potential size is unlimited and performance is not degraded when more servers are added.
DNS Domain Names
DNS is implemented as a hierarchical and distributed database containing various types of data, including host and domain names. The names in a DNS database form a hierarchical tree structure called the domain namespace. Domain names consist of individual labels separated by dots. A fully qualified domain name (FQDN) uniquely identifies the hosts position within the DNS hierarchical tree by specifying a list of names separated by dots in the path from the referenced host to the root.
|
Type |
Description |
Example |
|
Root Domain |
The top of the tree, representing an unnamed level. When used in a DNS domain name, it is stated by a trailing period (.) to designate that the name is located at the root or highest level of the domain hierarchy. In this occurrence, the DNS domain name is considered to be complete and points to an exact location in the tree of names. Names stated this way are called fully qualified domain names (FQDNs). |
A single period (.) |
|
Top Level Domain |
A name used to indicate the type of organization using the name. Top level domain can also specify a country or region. |
.ch for Switzerland, .com for a commercial use on the Internet |
|
Second Level Domain |
Second level domain can be of variable length. It is registered to a individual or organization for use on the Internet. Second level domain is following the appropriate top-level domain, depending on the type of organization or geographic location where a name is used. |
piir.ch is the second level domain registered to a private entity as holder of this domain, slackware.com is registered to Slackware Inc. |
|
Subdomain |
Additional names that are derived from the registered second-level domain name. The holder of the second level domain can add these depending on its needs, independently of the naming scheme of the deriving domain. These include names added to grow the DNS tree of names in an organization and divide it into departments or geographic locations. |
tech.piir.ch which is a fictitious subdomain but could be used by piir.ch for any (technical) purposes |
|
Host or Resource Name |
Names to identify a specific resource. Typically, the leftmost label of a DNS domain name identifies a specific computer on the network.. |
werder.piir.ch is the hostname, www.piir.ch is the CNAME pointing to the hostname |
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/region. Top level domain management in Switzerland for example is done by Switch (www.switch.ch).
Examples of top-level domain names
- com = commercial organizations
- org = non profit organizations
- edu = educational organizations
- gov = government organizations
- ch = two letter country code for Switzerland
- de = two letter country code for Germany
Domain name hierarchy
The DNS domain namespace is based on the concept of a tree of named domains. Each level of the tree can represent either a branch or a leaf of the tree. A branch is a level where more than one name is used to identify a collection of named resources. A leaf represents a single name used once at that level to indicate a specific resource.
The previous figure shows how piir.ch is assigned authority by the Internet root servers for its own part of the DNS domain namespace tree on the Internet. DNS clients and servers use queries as the fundamental method of resolving names in the tree to specific types of resource information. This information is provided by DNS servers in query responses to DNS clients, who then extract the information and pass it to a requesting program for resolving the queried name. In the process of resolving a name, keep in mind that DNS servers often function as DNS clients, querying other servers in order to fully resolve a queried name.
Resource Records
A DNS database consists of resource records (RRs). Each RR identifies a particular resource within the database. There are various types of RRs in DNS. The following table provides information about structure of common resource records.
|
Description |
Type |
Data |
|
Start of Authority |
SOA |
Owner Name Primary Name Server DNS Name, Serial Number Refresh Interval Retry Interval Expire Time Minimum TTL |
|
Host |
A |
Owner Name (Host DNS Name) Host IP Address |
|
Name Server |
NS |
Owner Name Name Server DNS Name |
|
Mail Exchanger |
MX |
Owner Name Mail Exchange Server DNS Name, Preference Number |
|
Canonical Name (alias) x |
Owner Name (Alias Name) Host DNS Name |
Zone Files
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. A DNS database can be partitioned into multiple zones. A DNS server can be configured to host zero, one or multiple zones.
A zone contains information about all names that end with the zone’s root domain name. Each zone is anchored at a specific domain name referred to as the zone’s root domain. 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) resource record (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.
A name within a zone can also be delegated to a different zone that is hosted on a different DNS server. Delegation is a process of assigning responsibility for a portion of a DNS namespace to a DNS server owned by a separate entity.
DNS database replica
Multiple zones can represent the same portion of the namespace. We distinguish three types:
- Primary
- Secondary
- Stub
Primary is a zone to which all updates for the records that belong to that zone are made. This zone is writeable. A secondary zone is a read-only copy of the primary zone. A stub zone is a read-only copy of the primary zone that contains only the resource records that identify the DNS servers that are authoritative for a DNS domain name. Any changes made to the primary zone file are replicated to the secondary zone file. DNS servers hosting a primary, secondary or stub zone are said to be authoritative for the DNS names in the zone.
A DNS server can host both a primary zone (which has the writeable copy of a zone file) and a separate secondary zone (which obtains a read-only copy of a zone file). A DNS server hosting a primary zone is said to be the primary DNS server for that zone, and a DNS server hosting a secondary zone is said to be the secondary DNS server for that zone.
Zone transfer
A zone transfer is the process of replicating a zone file to multiple DNS servers. This is achieved by copying the zone file from one DNS server to a second DNS server. Zone transfers can be made from both primary and secondary DNS servers.
A master DNS server is the source of the zone information during a transfer. The master DNS server can be a primary or secondary DNS server. If the master DNS server is a primary DNS server, then the zone transfer comes directly from the DNS server hosting the primary zone. If the master server is a secondary DNS server, then the zone file received from the master DNS server by means of a zone transfer is a copy of the read-only secondary zone file.
The zone transfer is initiated in one of the following ways:
- The master DNS server sends a notification to the secondary DNS servers of a change in the zone file
- The name server service on the secondary DNS server starts, or the refresh interval of the zone has expired (by default it is set to 900s in the SOA RR of the zone). If true, the secondary DNS server will query the master DNS server for the changes
There are two types of zone file replication. The first, a full zone transfer (AXFR), replicates the entire zone file. The second, an incremental zone transfer (IXFR), replicates only records that have been modified.
Database querying
DNS queries can be sent from a DNS client (resolver) to a DNS server, or between two DNS servers. A DNS query is merely a request for DNS resource records of a specified resource record type with a specified DNS name.
There are two types of DNS queries that may be sent to a DNS server:
- Recursive
- Iterative
Recursive query
A recursive query forces a DNS server to respond to a request with either a failure or a successful response. DNS clients (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 DNS client. The recursive query is the typical query type used by a resolver querying a DNS server and by a DNS server querying its forwarder, which is another DNS server configured to handle requests forwarded to it.
When a DNS server processes a recursive query and the query cannot be resolved from local data (local zone files or cache of previous queries), the recursive 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 the root DNS servers of the Internet domains. (If the DNS server is configured with a forwarder, the forwarder is used before a root server is used.)
Iterative query
An iterative query is one in which the DNS server is expected to respond with the best local information it has, based on what the DNS server knows from local zone files or from caching. This response is also known as a referral if the DNS server is not authoritative for the name. If a DNS server does not have any local information that can answer the query, it simply sends a negative response. A DNS server makes this type of query as it tries to find names outside of its local domain(s) (when it is not configured with a forwarder). It may have to query a number of outside DNS servers in an attempt to resolve the name.
Time to Live for Resource Records
The Time to Live (TTL) value in a resource record indicates a length of time used by other DNS servers to determine how long to cache information for a record before expiring and discarding it. Most resource records inherit the minimum (default) TTL of one hour from the start of authority (SOA) resource record, which prevents extended caching by other DNS servers.
A DNS client resolver caches the responses it receives when it resolves DNS queries. These cached responses can then be used to answer later queries for the same information. The cached data, however, has a limited lifetime specified in the TTL parameter returned with the response data. TTL ensures that the DNS server does not keep information for so long that it becomes out of date. TTL for the cache can be set on the DNS database, per zone through the minimum TTL field of the SOA recordb as well as on the DNS client resolver side by specifying the maximum TTL the resolver allows to cache the resource records.
The two competing factors to consider when setting the TTL are 1: The accuracy of the cached information and 2: The utilization of the DNS servers and the amount of 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 do not reset it based on their own TTL. Consequently, entries truly expire rather than live in perpetuity as they move from DNS server to DNS server with an updated TTL.