The Domain Name Service (DNS), which translates uniform resource locators into web addresses, is one of the most utilized and important protocols for email and Internet usage. However, it is also one of the most poorly understood and mismanaged of the protocols. It is my hope that in the present discussion that we may address that issue.
The Domain Name Services, which is also known as the Domain Name System came about as a result of issues that were apparent in the hosts.txt file of DARPA Internet computers (Mockapetris & Dunlap, 1988). Computers had long used a convention of contacting each other by name, as opposed to number, and the hosts file was introduced to facilitate the translation of host name to IP address. The hosts file within systems were very useful as they provide computers with a name to number association, as such the computer does not to query another computer for that information, which speeds up access to a requested site. However, there were a few major problems with the hosts file, such as the constant need to update its’ entries, and the issue of it not scaling well. Thus, RFC 882 saw the advent of a worldwide, decentralized, distributed database system, that is DNS, that would perform the host name to IP address mapping that the hosts file had done (Mockapetris, 1983a).
When graphically depicted the hierarchical, inverted, tree-like structure of DNS is very reminiscent of the UNIX file system. It begins with the DNS namespace, represented by a dot (.),which is the root domain. From this flows the top-level domains (TLDs), such as .com, .org, .net, .edu, et cetera (Deccio, Sedayao, Kant, & Mohapatra, 2012). The administrative and technical infrastructure within the namespace is a zone, which contains individual records that are called Resource Records (RR), which we will discuss in greater detail in our next section..
Typically, it is the forward lookup zone that stores the hostname to IP address relations, and where a computer would request the IP address of a specific hostname, and from where the the result would be returned. Thus, it is at this stage that the client-side of the DNS is utilized, which is called a DNS resolver. The resolver is tasked with initiating and sequencing the queries that provide the resolution of the resource, which is the translation of a domain name into an IP address (Dostálek & Kabelová, 2006).
Start of Authority (SOA). The SOA will identify the DNS server that is authoritative for all information within the domain. Administratively, it would list the email address of the person in charge of the domain. Technically, it will control when the secondary servers check for changes to the zone file, and how long the secondary servers keep the zone file active when the primary server cannot be contacted (Nikkel, 2004).
Name Servers (NS). These servers store information about the tree structure of the domain, as well as specifying a name server for the domain, which allows DNS lookups within various zones. Ideally, there should be a primary and secondary name server designated within this record (Mockapetris, 1983b).
A Record. The A Record returns a 32-bit IPv4 address, which is typically used to map hostnames to an IP address of the host. This record contains the FQDN (fully qualified domain name), IP address, and the TTL (time to live) in seconds that the record will be cached in resolving name servers (Mockapetris, 1987).
CNAME. The Canonical Name record which is abbreviated as the CNAME record is an alias of one name to another: and will allow the DNS lookup to continue retrying the lookup with the new name.In essence it is a nickname or alias pointer, as it will map an alias to the real or Canonical name (Lottor, 1987).
MX. The mail exchange record will map a domain name to a list of message transfer agents, mail transfer agent (MTA) or mail relay, which is software that transfers electronic mail messages from one computer to another using a client–server application architecture.for that domain. Each MX record will be matched with domain name consisting of a preference value and the name of a host (Partridge, 1986).
PTR. As with the CNAME, the PTR will point to the Canonical name; it is typically used to perform a reverse DNS lookup i.e. a IP to host mapping (Lottor, 1987).
HINFO. This record may be used to record information about the type of machine and the operating system being utilized.
The DNS Protocol & Commands
For performing queries over the Internet, but not zone transfers, it is recommended that UDP port 53 be used. The message size should be limited to a block-size limit of 512 bytes, with the exclusion of the UDP or IP header (Mockapetris, 1987; Aitchison & Topjian, 2011). For zone transfers, a DNS query type AXFR that is used to replicate DNS databases, the TCP port 53 is recommended, and may be utilized for messages that exceed the 512-byte limit (Bellis, 2010).
It should be apparent that name server availability is a mission-critical concern, as such one solution is to have primary, secondary, and in some instances tertiary, and quaternary name servers. Thus, if one server does not respond to the host, then another would be queried in a randomized, measured response time, or round-robin manner for load-balancing and to decrease response times (Aitchison, & Topjian, 2011).
UNIX DNS Commands
Nonetheless, inevitability a problem will occur, at that point the following DNS commands may be useful for trouble-shooting name resolution issue issues, and may be ran from the CLI of the UNIX terminal.
host. This is arguably the simplest way to resolve a domain name to an IP address, and it may also be used for reverse DNS lookup as well.
nslookup. This utility may be used as a single line command, or interactively to query a DNS name server of choice, to obtain domain name or IP address mapping information, or other desired DNS record (Anuszkiewicz, 2001).
dig. The “domain information groper” (dig) is similar in functionality to the nslookup command; however it can perform interactive or batch commands as well (Postel et al., 1990).
traceroute. This utility lists the routers an IP packet travels through in order to reach a particular host, using ICMP protocol traffic control messages to do so. Based upon this, we are able to contact or diagnose DNS server that is only reachable through UDP and to which access is filtered (Blancher, 2003).
/etc/resolv.conf. While not a command, it is nonetheless a very important file, as it is the resolver configuration file, which contains information that is read by the resolver routines. It is typically a plain-text file, much like the hosts file, and may be manually created or by applications that manage the configuration tasks of the system. The resolv.conf file may be used in conjunction with the dnsproxy daemon, a proxy for DNS queries, which forwards queries to two previously configured name servers; one for authoritative queries and another for recursive queries.
A useful application for this is the replacement of BIND servers with the djbdns alternative DNS implementation in ISP environments. These servers receive recursive queries from end-users and authoritative queries from outside at the same IP address. Other uses of this configuration are to proxy queries to the actual DNS server in a DMZ or behind a firewall (Cheswick & Bellovin, 1996).
Berkeley Internet Name Domain (BIND)
For the business entity and the average end-user, there is a wide array of DNS options. Of these the open-source Berkeley Internet Name Domain (BIND), originally developed for the BSD operating system is the most widely deployed. BIND is installed by default on most UNIX variants, and consists of a Name Daemon, that performs name resolution services that are compliant with DNS protocol standards. There is a resolver library is a collection of software components that aids in domain name and Internet address resolution. Also included with BIND are development and diagnostic tools (Albitz & Liu, 2006).