Skip to content

Appunti (anni precedenti al 2024/2025)

Questi appunti sono relativi a come funziona internamente il DNS. Argomento che dal 2024/2025 non è più parte del corso.

Zones

The name table does not exist in its entirety anywhere. Each name server contains a set of RRs of the name table, i.e., the name table is distributed. The distribution of the name table is based on the domain tree, as follows.

The domain tree is partitioned in zones. All domains of the same zone are stored on the same name server, that is the name server of the zone.

A zone is a partition of the domain tree rooted at a domain and that extends below that domain, either until leaf nodes of the domain tree or until the root of another zone. The root of the domain tree is a zone. All the children of the root (top level domains, TLD) are also zones.

Intuitively, one may think of a zone as of a subtree of the domain tree. This definition is not fully precise because the mathematical definition of a subtree consists of all the descendants of the root of the subtree, while in this case one or more of those descendants could be root of other zones.

The domain that is the root of a zone must contain a RR of type NS. A RR of this type maps the name of a zone to the name of the name server of that zone. The name of the name server of a zone may or may not be in that zone.

In order to contact the name server of a zone Z1, it is necessary to have two RRs: the RR of type NS mapping the name of Z1 to the name of a name server; and, the RR of type A mapping the name of that name server to the corresponding IP address.

Notes:

  • The domain tree representation does not include its partitioning in zones (the fact that a domain is the root of a zone is described by the existence of a RR of type NS within that domain, but RRs are not part of a domain tree representation).
  • The domain tree representation does not include name servers.
  • A name server may be name server of one or more different zones.

As already observed, all domains of a zone are stored on the name server of that zone. Certain RRs must be stored also on other name servers, as follows:

  1. The pair of RRs of types NS/A for the root zone must be stored on every name server.
  2. The pair of RRs of types NS/A for zone Z1 must be stored on the name server of the zone above Z1 (actually, in case the name of the name server is not in Z1, then this constraint applies only to the NS RR and it does not apply to the A RR; this special case is beyond the scope of the course: we may forget about this special case and assume that NS/A pairs for Z1 are always stored in the zone above Z1; more details in the appendix of this page).

RRs specified in 2 are called glue information. These requirements must be satisfied to guarantee that, for any possible name, it is always possible to contact the server that is certainly able to respond to a request for that name.

Iterative name resolution

A common configuration for organizations that have a name server N is as follows:

  1. N acts as the default name server for all the hosts internal to the organization.
  2. Any DNS outbound traffic not originated by N is blocked at the organization boundary.
  3. Any DNS inbound traffic not directed to N is blocked at the organization boundary.
  4. All hosts in the organization (i.e., all processes that have to translate a domain name) send their requests to N and ask it to perform a recursive resolution. This means that, in case N does not know the required RR, N locates the server where the required RR is stored, obtains the RR and responds with the required RR.
  5. N executes recursive resolutions only for DNS requests originated by hosts internal to its organization.

Configurations of this kind allow organizations to centralize the monitoring of all name resolutions originated within the organization, as well as the blocking of selected name resolutions. Rules 2 and 3 are implemented at the IP networking layer.

The procedure executed at step 4 above by N for obtaining a RR that is not locally available is called iterative name resolution. This procedure consists in navigating along name servers starting from the name server of the root zone, based on the domain name itself (one label at a time, right to left) and using the glue information appropriately. (we omit the details). The name resolution procedure, thus, is guaranteed to complete after contacting a very small number of name servers.

Note that iterative name resolution is performed only by name servers. It is never performed by hosts (that are not name servers): such hosts always send requests to their respective default name server; that name server will always obtain the required RRs as needed, in case it does not have them locally available then the default name server will navigate in the domain tree starting from the root zone (i.e., the default name server will execute an iterative resolution).

Replication

The name server of a zone must be replicated. That is, each zone must have multiple name servers each storing a copy of all RRs of that zone. This requirement ensures that failure or unreachability of a name server does not make a full zone, and all zones below that zone, not accessible.

One of the name servers of a zone is called primary; the other name servers are called secondary. When a RR has to be modified, it is modified only at the primary by the zone administrator; secondary name servers contact the primary name server periodically to be notified of all changes to RRs of the zone (including creation and deletion).

At a given instant, thus, different replicas for a zone could have different RRs for that zone. This feature is intrinsic into the DNS functioning. When a response contains a RR, the content of that RR does not have any information enabling to tell whether that RR is the most up-to-date copy.

All name servers of a zone must be described by NS/A pairs, that is, there must be one such pair for each name server replica; the NS RR will have the same name in all pairs (because they all describe the same zone) but different value (because each RR identifies a different name server for that zone). The requirements for the glue information apply to all these RRs.

Replicas of a zone are equivalent among themselves in the sense that RRs of type NS describing the name servers of that zone do not tell which name server is the primary.

Caching

Each name server maintains a local copy of all RRs that has seen in the past. This local copy is called cache. The cache is used for constructing responses. When a name server receives a request, it first analyzes the cache; the name server sends a request to a name server only in case the cache does not allow answering the request.

A RR may not remain in a cache indefinitely but it must be deleted after a time interval whose length is contained in the RR itself, in a column called TimeToLive (TTL).

A response obtained from a cache is called non authoritative and is flagged as such. In this case, the TTL of the returned RR is decremented of the time interval already spent in the cache. A response obtained from one of the name servers of the corresponding zone is called authoritative.

Notes:

  • The name server of a zone does not know how many copies of the RRs of that zone exist in the DNS caches distributed across the Internet.
  • When a RR is updated, the update is not immediately reflected to the copies of that RR possibly stored in DNS caches.
  • If the TTL value for a RR at the primary is T seconds, then it is guaranteed that all copies of that RRs will disappear everywhere after at most T seconds.

Glue information

This section elaborates on the following sentence from the "Zones" section:

The pair of RRs of types NS/A for zone Z1 must be stored on the name server of the zone above Z1 (actually, in case the name of the name server is not in Z1, then this constraint applies only to the NS RR and it does not apply to the A RR; this special case is beyond the scope of the course: we may forget about this special case and assume that NS/A pairs for Z1 are always stored in the zone above Z1).

I iterate that the content of this appendix is beyond the scope of the course.

Let us consider the following example. The name server of zone acm.org is named ns.yale.edu (i.e., the name server of a zone Z1 is not in Z1). According to our lectures, the name server of zone org must contain both of the following RRs (glue information):

  • acm.org NS ns.yale.edu
  • ns.yale.edu A IP-ns-y

This requirement guarantees that every iterative name resolution for a name whose suffix is acm.org and "passes through" the name server of zone org may continue with the next step, i.e., with the name server of zone acm.org.

Now suppose that only the first RR is stored in the name server of zone org. Would the above name resolution fail?

Let us consider a domain tree navigation for resolving a name whose suffix is acm.org, e.g., pippo.acm.org A ?. When the name server of zone org receives the request, it will now respond only with the first RR (as that name server does not have the second RR locally available in its glue information). The receiving name server, i.e., the name server that is executing the domain tree navigation would thus reason this way:

  1. The name server of zone org does not have the requested RR;
  2. however, it does know that acm.org is a zone and that the name server of this zone is ns.yale.edu;
  3. I thus have to continue the domain tree navigation by sending pippo.acm.org A ? to ns.yale.edu;
  4. I do not have the IP address of ns.yale.edu thus I have to execute another domain tree navigation for resolving ns.yale.edu A ?; having found this RR I will continue the navigation for resolving pippo.acm.org A ?

That is, the name resolution would not fail: the second domain tree navigation will pass through the name servers of the root zone, of zone edu, of zone yale.edu and will succeed. It follows that, in this case, the presence of ns.yale.edu A IP-ns-y is not needed in the glue information of zone org.

Now suppose that the name server of zone acm.org is named instead ns.acm.org (i.e., the name server of a zone Z1 is in Z1). According to our lectures, the name server of zone org must contain both of the following RRs (glue information):

  • acm.org NS ns.acm.org
  • ns.acm.org A IP-ns-o

Now suppose that only the first RR is stored in the name server of zone org. In this case, as explained in the following, the above name resolution will fail:

  1. The name server of zone org does not have the requested RR;
  2. however, it does know that acm.org is a zone and that the name server of this zone is ns.acm.org;
  3. I thus have to continue the domain tree navigation by sending pippo.acm.org A ? to ns.acm.org;
  4. I do not have the IP address of ns.acm.org thus I have to execute another domain tree navigation for resolving ns.acm.org A ?; having found this RR I will continue the navigation for resolving pippo.acm.org A ?

It is simple to realize that the domain tree navigation for ns.acm.org A ? will fail (or execute and endless loop):

  1. The name server of zone org does not have the requested RR;
  2. however, it does know that acm.org is a zone and that the name server of this zone is ns.acm.org;
  3. I thus have to continue the domain tree navigation by sending ns.acm.org A ? to ns.acm.org (endless loop!);

In summary:

  1. If the name server of a zone Z1 has a name in Z1 then the glue information for Z1 must contain two RRs (NS/A)
  2. If the name server of a zone Z1 has a name that is not in Z1 then the glue information for Z1 may contain only one RR (NS)
  3. To make things easier to understand and to remember, we assume that the glue information for Z1 always contain two RR (NS/A).