In any distributed environment, application programs use a name system to find addresses corresponding to machine names or, stated in a more general way, use name systems to find attributes associated with named objects[#!grapevine!#]. These name systems are essential to allow several sorts of bindings to take place.
In early days of ARPANET, or in small local networks with a dozen machines, a file containing a central database (like ``/etc/hosts'') can be reproduced by hand in every machine to solve the problem. However, in the current worldwide Internet, with hundreds of thousands machines, this method is no longer viable.
The domain name system (DNS) is a hierarchical, distributed naming system, designed to address the problem of explosive growth of the number of machines[#!comer-resumido!#]. It can be seen as some sort of hierarchical, distributed database, managed in a decentralized way, by thousands of administrators. It is hierarchical because the name space is structured like a tree. Each branch of the tree is called a (sub)domain. The tree can have as many levels as needed. It is distributed because the management of each domain can be delegated to a new machine and administrator. Because local domain administrators control their branch of the tree, they can add, delete or change names easily.
Figure 1 presents a small slice of the current DNS tree. The tree has a root and several branches. A domain name is similar to an Unix2file path name with components written from left to right and separated by a ``.'' (dot). A full qualified domain name, like ``dec4pt.puug.pt.'' is a path from a leaf up to the root (``.''). In general, the root domain name may be omitted. In almost all situations, ``dec4pt.puug.pt.'' denotes the same object as ``dec4pt.puug.pt''.
The DNS database contains attributes associated with names [#!rfc-1034!#]. These attributes are called resource records (RR). Several RRs can be associated with a name. Each one denotes the value of one attribute of the named object. There are several classes of RRs: A RRs (Address) allowing the association of an address with the name, NS RRs (Name Server) allowing the association of a pointer to a name server, MX RRs (Mail eXchanger) allowing the introduction of a mail relay willing to accept mail for the name [#!rfc-974!#], HINFO RRs (Host INFOrmation) allowing the introduction of information about a host, TXT RRs (TeXT) allowing the association of any comments with the name, CNAME RRs (Canonical NAME) allowing the introduction of aliases, etc.
Each branch of the tree is managed by a special program called a name server[#!bind!#]. Below is shown a portion of a dump of the set of RRs associated with the domain name ``puug.pt'' present in current the DNS database. The dump has been obtained with the user level utility nslookup (``Name System Lookup'') when querying the machine ``dec4pt.puug.pt''.
The example shows the use of several RRs associating attribute values with names. For example, MX RRs stating that the machine ``dec4pt.puug.pt'' is willing to receive mail addressed to ``user@puug.pt'' and to ``user@colombo.puug.pt'' and that machine ``inesc.inesc.pt'' is also willing to receive mail addressed to ``user@puug.pt'' (however, machine ``dec4pt.puug.pt'' should be used preferably), NS RRs stating the list of name servers knowing authoritative data (see below) about the domain ``puug.pt'', A RRs introducing the addresses of the machines ``dec4pt.puug.pt'' and ``colombo.puug.pt'', a HINFO RR introduction information about the machine ``dec4pt'', etc.
Any server or utility can interface the DNS system by quering name servers about RRs associated with a name[#!rfc-1035!#]. It is possible to query about any kind of attributes or about a specific kind of RR. If the server doesn't know the name, it answers with a list of name servers that can be queried instead. Eventually, with the list of name servers running authoritative for the root (see below). This would allow the querying client to walk from the root until the right branch of the tree.