Reserved Domains and Pseudodomains

It was later decided that other domains could also be used as TLD. Some TLD were reserved in
RFC 2606:

• The test domain for testing
• The example domain for creating documentation and examples
• The invalid domain for evoking error states
• The localhost domain for software loops

Domains that are not directly connected to the Internet can also exist, i.e., computers that do not
even use the TCP/IP network protocol therefore do not have an IP address. These domains are
sometimes called pseudodomains. They are meaningful especially for electronic mail. It is
possible to send an email into other networks and then into the Internet with the help of
a pseudodomain (like DECnet or MS Exchange).

In its internal network, a company can first use TCP/IP and then DECnet protocol. A user using
TCP/IP in the internal network (for example, Daniel@computer.company.com) is addressed from
the Internet. But how do you address a user on computers working in the DECnet protocol?

To solve this, we insert the fictive dnet pseudodomain into the address. The user Daniel is
therefore addressed Daniel@computer.dnet.company.com. With the help of DNS, the entire email
that was addressed into the dnet.company.com domain is redirected to a gateway in DECnet
protocol (the gateway of the company.com domain), which performs the transformation from
TCP/IP (for SMTP) into DECnet (for Mail-11).

Queries (Translations)

Most common queries are translation of a hostname to an IP address. It is also possible to request
additional information from DNS. Queries are mediated by a resolver. The resolver is a DNS
client that asks the name server. Because the database is distributed worldwide, the nearest name
server does not need to know the final response and can ask other name servers for help. The name
server, as an answer to the resolver, then returns the acquired translation or returns a negative
answer. All communication consists of queries and answers.

The name server searches in its cache memory for the data for the zone it administers during its
start. The primary name server reads data from the local disk; the secondary name server acquires
data from the primary name server by a query zone transfer of the administered zones and also
saves them into the cache memory. The data stored within the primary and secondary name
servers is called authoritative data. Furthermore, the name server reads from its memory
cache/hint the zone data, which is not part of the data from its administered zone (local disk), but
nonetheless enables this data to connect with the root name servers. This data is called
nonauthoritative data. In the terminology of BIND program version 8 and 9, we sometimes do
not speak of them as primary and secondary servers, but as master servers and slave servers.

Name servers save into their cache memory positive (and sometimes even negative) answers to
queries that other name servers have to ask for. From the point of view of our name server, this
data acquired from other name servers is also non-authoritative, thereby saving time when
processing repeated queries.

Requirements for translations occur in a user program. The user program asks a component within
the operating system, which is called a resolver, for a translation. The resolver transfers the query
for translation to a name server. In smaller systems, there is usually only a stub resolver. In such
cases, the resolver transfers all requirements by DNS protocol to a name server running on another
computer (see Figure 1.5). A resolver without cache memory is called a stub resolver. It is
possible to establish cache memory for a resolver even in Windows 2000, Windows XP, etc. This
service in Windows is called DNS Client. (I think this is a little bit misleading as a stub resolver is
not a proper DNS client!)

Some computers run only a resolver (either stub or caching); others run both a resolver and a name
server. Nowadays, a wide range of combinations are possible (see Figure 1.6) but the principle
remains the same:

1. The user inserts a command, then the hostname needs to be translated into an IP
   address (in Figure 1.6, number 1).
2. If the resolver has its own cache, it will attempt to find the result within it
   directly (2).
3. If the answer is not found in the resolver cache (or it is a stub), the resolver transfers
   the request to a name server (3).
4. The name server will look for the answer in its cache memory.
5. If the name server does not find the answer in its cache memory, it looks for help
   from other name servers.
6. The name server can contact more name servers by a process referred to as
   iteration. By iteration, the name server can access or contact a name server, which
   is an authority on the answer. The authoritative name server will then give a last
   resort answer (negatively if there is no information in DNS corresponding with the
   inserted name).
7. But if the process described above does not return the result fast enough, the
   resolver repeats its query. If there are more name servers listed in the resolver
   configuration, then it will send the next query to the next name server listed in the
   directory (i.e., another name server). The directory of name servers is processed
   cyclically. The cycle starts for the particular query from the name server, which is
   listed in the first position.

DNS uses both UDP and TCP protocols for the transport of its queries/answers. It uses port 53 for
both protocols (i.e., ports 53/UDP and 53/TCP). Common queries such as the translation of a
name to an IP address and vice versa are performed by UDP protocol. The length of data
transported by UDP protocol is implicitly limited to 512 B (a truncation flag can be used to signal
that the answer did not fit into 512 B and it is therefore necessary for the query answer to be
repeated by the TCP protocol). The length of UDP packets is limited to 512 B because a
fragmentation could occur for larger IP datagrams. DNS does not consider fragmentation of UDP
as sensible. Queries transporting zone transfer data occur between the primary and secondary
name servers and are transported by TCP protocol.

Common queries (such as the translation of a name to an IP address and vice versa) are performed
with the help of datagrams in UDP protocol. The translations are required by a client (resolver) on
the name server. If the name server does not know what to do, it can ask for translation (help)
from other name servers. Name servers solve questions among themselves by iteration, which
always starts from the root name server. More details are available in Section 1.10.

There is a rule in the Internet that a database with data needed for translations is always saved on
at least two independent computers (independent name servers). If one is unavailable, the
translation can be performed by the other computer.

In general, we cannot expect that all name servers are accessible all the time. If the TCP protocol
is used for a translation, attempts to establish a connection with an inaccessible name server would
cause long time intervals while the TCP protocol is trying to connect. Only when this time interval
is over is it possible to connect to the next name server.

The solution for this in UDP protocol is more elegant: A datagram containing a request for the
translation is sent to the first server. If the answer does not come back within a short time-out
interval, then a datagram with a request is sent to another name server, if the answer does not
come back again, it is sent to the next one, and so on. If all possible name servers are used, it will
start again from the first one, and the whole cycle repeats until the answer comes back or the set
interval times out.

Round Robin

Round Robin is a technique that can be used to equally load several machines (Load Balancing). It is
possible to use this technique for the majority of name servers (including Windows 2000/2003). This
is a situation where we have more than one IP address for one name in DNS. For example, we may
operate an exposed web server and because the performance of the machine is not
sufficient, we buy another or two more. We start running the web server on all three of them
(for example, www.company.com). The first one has an IP address 195.1.1.1, the second one
195.1.1.2, and the third one 195.1.1.3. There will be three records in DNS for www.company.com, and
each of them will have a different IP address. Round Robin technique ensures that the answer to the:

1. first query (to the first user) will be that the web server return addresses 195.1.1.1,
   195.1.1.2, and 195.1.1.3
2. the answer to the next query (to the second user) will be that the server return IP
   addresses 195.1.1.2, 195.1.1.3, and 195.1.1.1.
3. the answer to te next query (may be 3rd user) will return IP addresses 195.1.1.3,
   195.1.1.1, and 195.1.1.2.
4. procedure are repeating from 1st point again and again.

Comments

comments