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.

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 answer which the provider DNS receives is ns5.dynaccess-nameserver.com and 213.133.103.135.

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.