Parts of a domain name

Parts of a domain name

A domain name usually consists of two or more parts (technically labels), separated by dots. For example example.com.

• The rightmost label conveys the top-level domain (for example, the address www.example.com has the top-level domain com).
• Each label to the left specifies a subdivision, or subdomain of the domain above it. Note;"subdomain" expresses relative dependence, not absolute dependence. For example: example.com comprises a subdomain of the com domain, and www.example.com comprises a subdomain of the domain example.com. In theory, this subdivision can go down to 127 levels deep. Each label can contain up to 63 characters. The whole domain name does not exceed a total length of 255 characters. In practice, some domain registries may have shorter limits.
• A hostname refers to a domain name that has one or more associated IP addresses; ie: the www.example.com and example.com domains are both hostnames, however, the com domain is not.

DNS servers

The Domain Name System consists of a hierarchical set of DNS servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the name servers of any domains "beneath" it. The hierarchy of authoritative DNS servers matches the hierarchy of domains. At the top of the hierarchy stand the root nameservers: the servers to query when looking up (resolving) a top-level domain name (TLD).

DNS resolvers

A resolver looks up the resource record information associated with nodes. A resolver knows how to communicate with name servers by sending DNS queries and heeding DNS responses.

A DNS query may be either a recursive query or a non-recursive query:

• A non-recursive query is one where the DNS server may provide a partial answer to the query (or give an error). DNS servers must support non-recursive queries.
• A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries.

The resolver (or another DNS server acting recursively on behalf of the resolver) negotiates use of recursive service using bits in the query headers.

Resolving usually entails iterating through several name servers to find the needed information. However, some resolvers function simplistically and can only communicate with a single name server. These simple resolvers rely on a recursive query to a recursive name server to perform the work of finding information for them.

Address resolution mechanism

(This description deliberately uses the fictional .example TLD in accordance with the DNS guidelines themselves.)

In theory a full host name may have several name segments, (e.g ahost.ofasubnet.ofabiggernet.inadomain.example). In practice, in the experience of the majority of public users of Internet services, full host names will frequently consist of just three segments (ahost.inadomain.example, and most often www.inadomain.example).

For querying purposes, software interprets the name segment by segment, from right to left, using an iterative search procedure. At each step along the way, the program queries a corresponding DNS server to provide a pointer to the next server which it should consult.

As originally envisaged, the process was as simple as:

1. the local system is pre-configured with the known addresses of the root servers in a file of root hints, which need to be updated periodically by the local administrator from a reliable source to be kept up to date with the changes which occur over time.
2. query one of the root servers to find the server authoritative for the next level down (so in the case of our simple hostname, a root server would be asked for the address of a server with detailed knowledge of the example top level domain).
3. querying this second server for the address of a DNS server with detailed knowledge of the second-level domain (inadomain.example in our example).
4. repeating the previous step to progress down the name, until the final step which would, rather than generating the address of the next DNS server, return the final address sought.

The diagram illustrates this process for the real host www.wikipedia.org.

The mechanism in this simple form has a difficulty: it places a huge operating burden on the root servers, with each and every search for an address starting by querying one of them. Being as critical as they are to the overall function of the system such heavy use would create an insurmountable bottleneck for trillions of queries placed every day. The section DNS in practice describes how this is addressed.