DNS? What is it?

Usually, one accesses only those servers on the
internet which have a permanent connection. Only these computers have a
unique name und which they are accessible.
Don't confuse the name of the computer with a construction like
http://www.dynaccess.com. This is a name which was "developed for
humans". By contrast, servers communicate among themselves via
their official computer names. In our example
"www.dynaccess.com" this would be "62.116.180.101" -
that is, a combination of numbers!

The human names such as "www.dynaccess.com" were
developed many years ago in order to avoid having to permanently look up
the real computer names in a list on one's desk.
The internet cannot do much with human names such as
"www.dynaccess.com". It depends on servers which can tell it
which computer is really located behind "www.dynaccess.com",
so that the path to it can be "found".

These computers have a "name": DNS - domain-name server or
domain-name service. These DNS-servers thus transform a
"domain name (human name)" into a combination of
numbers known as an "IP".

www.dynaccess.com <---> 62.116.180.101

The "internet switchboards" (routers) now
know where these servers are located and can correctly route data
packets.

How does the DNS system function in practice?
It would certainly be a good idea to have a central database in which
the correspondences between IPs and internet addresses the world over
would be stored.

However, that is not the way the problem was solved. The reason that a
central system was not decided upon is certainly not due to disputes
between countries. The internet is somewhat more grown up than
political leaders.
A decentralised solution was decided upon. A decentralised solution
needs clever management which is immune to disruption - and to
cyberterror.

We would like to illustrate this system using a standard surfer as an
example:

A surfer connects to the internet via his internet provider and access
the page
http://www.dynaccess.com
in his browser.

The information is quickly available. However, many different DNS
systems have been working in order to provide the correct information.

1st step:
The DNS server of the provider is asked to provide the IP of the
webpage www.dynaccess.com.

Since it doesn't have this information, the DNS of
the provider has to look for the requested IP.
First it has to find out who manages the top-level domain
"com".
For this, there are 13 so-called ROOT NAMESERVERS. You can see their
locations on the map.

The provider DNS receives the information that
VeriSign
is responsible for this. Actually, this is 13 nameservers at different
locations for redundancy and to distribute the load.
This nameserver is still not able to deliver the IP for the internet
address www.dynaccess.com.
Instead, it has information about who manages this domain.

The provider DNS had to wait some time for this
information, but in the end it received the information it needed.

www.dynaccess.com <---> 62.116.80.101

Why so complicated? Can't it be done more simply?

This is a valid question. But perhaps we are lucky that such a
complicated concept was decided upon a long time ago. Since with the
number of domains which exist in the world today it wouldn't be possible
to smoothly operate a central management with the technology available
and in use today.

The multi-tiered concept has an acceleration feature
In order to find out the IP for a given internet address, several steps
are needed. Just these DNS queries would result in a gigantic data
transfer if there weren't a more clever solution.

Cache as cache can
Whenever one needs to speed up the internet, one makes use of temporary
storage, or caching.
In the example above, this means that the provider DNS
"remembers" who manages the TLD "com". In addition,
for repeated requests it remembers who manages the domain
"dynaccess.com". It can also remember the IP.
The traffic is thus greatly reduced since only those queries need to be
processed whose answers are not known to the nameserver of the provider.

TTL - Time To Live
Caching information is always bad if this information can change and
thus lead to wrong information being distributed.
In order to avoid this, the feature TTL was "invented".
The TTL value is a time span for which another nameserver is allowed to
distribute cached information. After this time expires, it is required
to request this information anew.
The TTL values for different types of information can take on different
values; it is thus variable.

Our success is not a real secret
This TTL value is also the entire secret of DynAccess. We set this
to such a small value that it has to be constantly requested from
our nameserver and thus no system anywhere in the world can have
obsolete information.
In practice, normal systems have a TTL value of 2 days.