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 "126.96.36.199" -
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 <---> 188.8.131.52
The "internet switchboards" (routers) now
know where these servers are located and can correctly route data
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
A decentralised solution was decided upon. A decentralised solution
needs clever management which is immune to disruption - and to
We would like to illustrate this system using a standard surfer as an
A surfer connects to the internet via his internet provider and access
in his browser.
The information is quickly available. However, many different DNS
systems have been working in order to provide the correct information.
The DNS server of the provider is asked to provide the IP of the
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
For this, there are 13 so-called ROOT NAMESERVERS. You can see their
locations on the map.
The provider DNS asks a root nameserver who manages the TLD
The provider DNS receives the information that
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
Instead, it has information about who manages this domain.
Provider DNS asks a.gtld-servers.net who manages the domain
The answer which the provider DNS receives is
ns5.dynaccess-nameserver.com and 184.108.40.206.
Provider DNS asks ns5.dynaccess-nameserver.com (220.127.116.11),
which IP corresponds to the internet address
The provider DNS had to wait some time for this
information, but in the end it received the information it needed.
www.dynaccess.com <---> 18.104.22.168
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
In practice, normal systems have a TTL value of 2 days.