DNS is a hierarchical, decentralized system for mapping internet names to resources, most notably to IP addresses. It does this by designating authoritative name servers for each domain. Authoritative name servers can delegate authority over subdomains to other name servers. Thus, DNS provides both a form of decentralization and fault-tolerance.

From the earliest days of the internet, the idea of mapping easily-remembered names to less easily-remembered numbers (such as IP addresses). ARPANET used a text file called HOSTS.TXT (/etc/hosts on UNIX-based systems) that mapped hostnames to their numerical addresses. At the time, addresses were added manually.

Even when the list was relatively small, this manual system was cumbersome and prone to error. By the early 1980s, however, maintaining a single, centralized list became unmanageable, and the growing networks required an automated method of maintaining a list that mapped names to addresses. DNS became that method.

The domain name space is a tree-like structure. At the top is the root zone; the root-zone DNS servers are the authoritative servers for top-level domains (for example, .com, .edu, .net, and .uk). Every DNS query either starts with a query to a root-zone server or uses information originally obtained from one.

The following table lists some of the top-level domains:

Lower-level domains are controlled by the owners of those domains and are largely open for use however those domain owners see fit. However, the top-level domains tend to be tightly controlled by the Internet Assigned Numbers Authority (IANA), the subsidiary of the Internet Corporation for Assigned Names and Numbers (ICANN) to which the management of root zones was delegated.

DNS solves the problem of name resolution by having specific servers that act as name servers. These servers run DNS server software and have the responsibility of receiving, processing, and replying to hosts that need to resolve hostnames to IP addresses. Because the namespace is extremely large, however, there is a good chance that the first DNS server that receives a query will not have the record requested. In such cases, the DNS server will ask another DNS server whether it has a record for the host name.

DNS queries can be either iterative or recursive. In the case of a recursive query, the client asks the DNS server for either the answer to the query or an error message that the information it is looking for cannot be found anywhere. It is the responsibility of the DNS server to do what is necessary to get the job done: to query other DNS servers until it gets the answer, or until it fails to get the answer.

When a client makes an iterative query, the client is essentially asking the DNS server for an answer to the query if it has the answer. If it does not have the answer, the DNS server provides a referral, which is another DNS server that might have the answer (this is typically an authoritative server at a lower level in the hierarchy of servers).

Although the most common type of a DNS database entry is an A record, which maps a hostname to an IP address, there are other types of records (these are specified by RFC 1035, except where otherwise noted):

• Start of Authority (SOA): This is a record of information containing data on DNS zone transfers and other DNS records.
• Name Server (NS): This stores information that identifies the authoritative name servers in the domain store information for the domain zone.
• Canonical Name (CNAME): This stores additional hostnames or aliases for hosts in the domain. When a client performs a DNS lookup on a non-canonical name, such as an alias, the DNS server will look up the canonical name and continue the search with the canonical name.
• Pointer (PTR): A pointer to the canonical name. Unlike a lookup involving a CNAME, DNS processing stops and just the CNAME is returned. It is most often used in reverse-DNS lookups (in which the client tries to find the hostname, given the IP address), but it is also used for other purposes, such as DNS-SD.
• IPv6address (AAAA): Stores information for IPv6 (128-bit) addresses. Specified by RFC 3596.
• IPv4 address (A): As mentioned before, stores information for IPv4 addresses, and is most often used to map hostnames to IP addresses.
• Mail Exchange (MX): Stores information about where mail for the domain is to be delivered. Specified by RFC 1035 and RFC 7505.

Although DNS has served the purpose for which it was created very well, it is not without issues. The first problem is security issues. DNS was first developed in the 1980s, when the internet was not open to the general public. The rapid expansion of the internet in the 1990s changed the security requirements for DNS; in particular, there was a greater need to protect the integrity of DNS data.

One security vulnerability is DNS cache-poisoning (also called DNS-spoofing). If a DNS server does not have a record mapping a hostname to the IP address, it will request the record from another DNS server. This occurs recursively until the record is found. When the server gets a reply, it will often cache the reply for increased performance. If the reply comes from a nefarious source, however, the record may contain false information (mapping the hostname to the wrong IP address), and if the DNS server stores this false record in its cache, then the cache is poisoned. The usual objective is to redirect traffic to a node under the control of the attacker.

DNS cache poisoning has taken several forms over the years. One form was the unrelated data attack. This method entailed the attacker making a DNS query for a nonexistent hostname within a domain controlled by the attacker. The request would be a recursive query, thus ensuring that the DNS server would make additional queries by itself. Eventually, the DNS server would make a query to the authoritative DNS server for the domain. Since the domain is under the control of the attacker, so is the authoritative DNS server. The attacker will answer the query, and the answer can contain unrelated information for other domains. This bogus information would thus poison the DNS server's cache.

The solution to this form of attack was to prohibit anything not related to the original query from being cached. However, this did not eliminate another form of cache poisoning: the related data attack. It was similar to the unrelated data attack in that it started with the attacker making a DNS query for a nonexistent domain within a domain under their control. The remote DNS server's query would eventually reach the attacker's DNS server. The data returned by the attacker has to be related to the query, but there are several relevant records that aren't related to the mapping of hostnames to IP addresses, for example, NS, CNAME, and MX. The attacker can insert bogus data in those records, and thus poison the remote DNS server's cache.

The solution to this form of attack is for the remote DNS server to look through these records, and discard all data not related to the domain for which the attacker's DNS server is responsible. Still, in spite of the fact that many of these forms of attacks have been rendered obsolete, DNS-spoofing and cache-poisoning remain a threat.

The solution to such attacks is to make sure DNS responses come from an authoritative source. One way to accomplish this is to use Domain Name System Security Extensions (DNSSEC), a suite of specifications for securing DNS records. The main mechanism for doing this is by digitally signing DNS records using public-key cryptography. This records are verified using a chain of trust that is recursively verified by all DNS servers up to the root server.

DNS also raises privacy issues. Even when DNS records cannot easily be spoofed or modified, a person with access to the DNS server or who is able to intercept the traffic between the client and the DNS server can obtain the client's IP address, which often identifies the user. This information can then be used to track the user and the websites and domains they visit.

There are different ways to address these privacy issues. One is to use a proxy; instead of connecting directly to a site, the end user connects to a proxy, which then acts as an intermediary, connecting to the site and sending data to and from the end user. Examples of proxies include The Onion Router (Tor), which directs traffic through a vast, volunteer overlay network of thousands of relays and is designed to conceal a user’s location and activity. Another example of a proxy is a virtual private network (VPN), which involves setting up an encrypted tunnel to a server, which serves as a proxy for the end user. Of course, using a proxy involves an increase in latency (the time it takes to receive and send data); proxies sometimes cache site data as well, so the data you receive may not be up to date.

Another possible solution is to connect to an intermediate DNS server configured with minimal logging, which can be used instead of DNS servers whose privacy policy is either unknown or is known to be untrustworthy. Such servers are likely to become more commonplace in the future.