The root servers are the starting point for all **name resolution** within the DNS.
Name Resolution
~~~~~~~~~~~~~~~
So far all the emphasis has been on how the DNS stores its authoritative domain (zone) data. End-user systems
use names (an email address or a web address) and need to access this authoritative data to obtain an IP address, which
they use to contact the required network resources such as web, FTP, or mail servers. The process of converting a
domain name to a result (typically an IP address, though other types of data may be obtained) is generically called **name resolution**, and is handled by
**resolvers** (also known as **caching name servers** and many other terms). The following diagram shows the typical name resolution process:
..figure:: name-resolution.png
:align:center
Authoritative Name Servers and Name Resolution
An end-user application, such as a browser (1), when needing to resolve a name such as **www.example.com**, makes an
internal system call to a minimal function resolution entity called a **stub resolver** (2). The stub resolver (using stored
IP addresses) contacts a resolver (a caching name server or full-service resolver) (3), which in turn contacts all the necessary
authoritative name servers (4, 5, and 6) to provide the answer that it then returns to the user (2, 1). To improve performance,
all resolvers (including most stub resolvers) cache (store) their results such that a subsequent request for the same data
is taken from the resolver's cache, removing the need to repeat the name resolution process and use time-consuming resources. All communication between
the stub resolver, the resolver, and the authoritative name servers uses the DNS protocol's query and response message pair.
.._referral:
.._recursive_query:
.._iterative_query:
DNS Protocol and Queries
~~~~~~~~~~~~~~~~~~~~~~~~
DNS **queries** use the UDP protocol over the reserved port 53 (but both TCP and TLS can optionally be used in some parts of the network).
The following diagram shows the name resolution process expressed in terms of DNS queries and responses.
..figure:: recursive-query.png
:align:center
Resolvers and Queries
The stub resolver sends a **recursive query** message (with the required domain name in the QUESTION section of the query) (2) to the resolver.
A **recursive** query simply requests the resolver to find the complete answer. A stub resolver only ever sends recursive queries
and always needs the service of a resolver. The response to a recursive query can be:
1. The answer to the user's QUESTION in the ANSWER section of the query response.
2. An error (such as NXDOMAIN - the name does not exist).
The resolver, on receipt of the user's recursive query, either responds immediately, if the ANSWER is in its cache, or accesses
the DNS hierarchy to obtain the answer. The resolver always starts with root servers and sends an **iterative query** (4, 5, and 6). The
response to an iterative query can be:
1. The answer to the resolver's QUESTION in the ANSWER section of the query response.
2. A **referral** (indicated by an empty ANSWER section but data in the AUTHORITY section,
and typically IP addresses in the ADDITIONAL section of the response).
3. An error (such as NXDOMAIN - the name does not exist).
If the response is either an answer or an error, these are returned immediately to the user (and cached for future use). If the response
is a referral, the resolver needs to take additional action to respond to the user's recursive query.
A referral, in essence, indicates that the queried server does not know the answer (the ANSWER section of the response is empty), but it
refers the resolver to the authoritative name servers (in the AUTHORITY section of the response) which it knows about in the
domain name supplied in the QUESTION section of the query. Thus, if the QUESTION is for the domain name **www.example.com**, the root
server to which the iterative query was sent adds a list of the **.com authoritative name servers** in the AUTHORITY section.
The resolver selects one of the servers from the AUTHORITY section and sends an
iterative query to it. Similarly, the .com authoritative name servers send a referral containing a list of the **example.com** authoritative name servers.
This process continues down the DNS hierarchy until either an ANSWER or an error is received, at which point the user's original recursive query
is sent a response.
..Note:: The DNS hierarchy is always accessed starting at the root servers and working down; there is no concept of "up" in the DNS hierarchy. Clearly,
if the resolver has already cached the list of .com authoritative name servers and the user's recursive query QUESTION contains a domain name
ending in .com, it can omit access to the root servers. However, that is simply an artifact (in this case a performance benefit) of
caching and does not change the concept of top-down access within the DNS hierarchy.
The insatiably curious may find reading :rfc:`1034` and :rfc:`1035` a useful starting point for further information.
DNS and BIND 9
~~~~~~~~~~~~~~
BIND 9 is a complete implementation of the DNS protocol. BIND 9 can be configured (using its ``named.conf`` file) as
an authoritative name server, a resolver, and, on supported hosts, a stub resolver. While large operators
usually dedicate DNS servers to a single function per system, smaller operators will find that
BIND 9's flexible configuration features support multiple functions, such as a single DNS server acting
as both an authoritative name server and a resolver.
Example configurations of basic :ref:`authoritative name servers<config_auth_samples>` and
:ref:`resolvers and forwarding resolvers<config_resolver_samples>`, as
well as :ref:`advanced configurations<Advanced>` and :ref:`secure configurations<Security>`, are provided.
