Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
This article is about the Domain Name System (DNS) and explains how the “Internet’s telephone book” works. Alongside the fundamental details of name resolution on the Internet, we also look at special topics like administering DNS records in dynamic environments and debugging DNS setups during operation. We look at it within the technical framework of Univention Corporate Server, because it contains not only a dyed-in-the-wool DNS server, but also diverse tools to make managing DNS records significantly easier.
The Domain Name System, DNS for short, is an absolutely elementary component of the Internet. While many users and most admins have some idea of the terms “DNS server” or “name server”, the actual structure of the DNS system and its basic functionality is often unclear. Therefore, it is not a bad idea to look at the central aspects of the topic DNS, before looking as specific aspects of DNS in detail.
The phenomenon given the simple name “the Internet” is actually a global network of very many individual computers. Naturally, direct connections do not exist from each computer to every other computer. Instead, the computers comprising the Internet are partitioned into individual network segments. Within their network segments, the systems communicate directly with one another.
If a server from one segment wants to connect to a server from a different segment, it must use a router. But how does a server know how to reach another local server, or another server in a different segment of the network?
Here is where IP addresses come into play. An IP address is a sequence of numbers in 32 bits (for IPv4) or 128 bits (for IPv6) “IP” stands for “Internet Protocol”, which highlights this principle’s general validity. The IP address of the computer containing this blog, for example, is
184.108.40.206 (IPv4) and
2001:8d8:100f:f000::219 (IPv6) (see Fig. 1).
You can see that when a reader wants to access this blog via its IP address, they need to remember a complicated sequence of numbers. This is difficult for IPv4, but for IPv6 it is practically impossible – and this IPv6 address is not as complicated as it theoretically could be! Just imagine that you had to remember all the sequences of numbers just for the websites one uses regularly. It’s impossible!
The founding fathers of the Internet already realized that this would be a problem. They thought up a system which translated the complicated IP addresses into understandable texts (“hosts” or “host names”). For example, the IP addresses named above translate to blog.univention.de. And this can be remembered much easier than the actual IP addresses.
However, this system brings up a new question: how does the web browser know that it needs the server with IP address
220.127.116.11 when the user types https://blog.univention.de/ into the address bar? This is where the Domain Name System servers, DNS servers for short, come into play, because they function like a sort of telephone book and know which IP addresses belong to which names. It works the other way too, of course: individual IP addresses can have names defined in text form.
Relief for admins: Automatic processing of DNS records – and much more. Discover the possibilities of Univention Corporate Server with the free Core Edition!
Before we go into the details of DNS, it is worth having a little excursion into its history. DNS is not a new invention, but is one of the oldest principles of the Internet. It goes back to the American Paul Mockapetris, and 1983. It came about from necessity: the predecessor of what is now the “Internet” was a network purely for research called ARPANET. This grew rapidly during the 70s.
The idea of combining IP addresses with host names which could be remembered better already existed before the DNS system. One configured the host record statically on the computers with a file called
HOSTS.TXT). This required, however, that there was a central instance which could maintain this file because it knew all the computers and their IP addresses.
ARPANET, however, grew so quickly in the 70s that this was no longer possible in practice. Thus, Mockapetris came up with the basis of DNS and wrote them in RFC 882 and 883, which were later replaced by 1034 and 1035. What is particularly interesting is that DNS has not fundamentally changed in all the years since. Over the years, new functions have been added all the time, but the basic principles of the idea are still the same as nearly 40 years ago. Indeed, almost all updates to DNS over the years have been mainly to make the administration and use of name servers easier. Other improvements have been made to security. The possibility of exchanging DNS records between servers using IXFR commands was not provided for when DNS was started. Digital signatures for DNS records (DNSSEC) which are designed to stop misuse was also not important in 1983. Today both functions are standard and enjoy great popularity.
Without name servers, the Internet would not really be usable anymore. It is obvious that a single name server cannot answer all the requests for the whole Internet. The load would be far too much for an individual server to handle. For this reason, the creators of the DNS system working alongside Paul Mockapetris came up with a mechanism which spreads the load out over as many servers as possible.
The schema designates individual DNS servers to be responsible for particular domains or addresses, while other DNS servers are responsible for other domains and IP addresses. What is important is that admins operating DNS servers differentiate between two types of DNS server.
Authoritative DNS servers may also act as recursive DNS servers for local clients but they do not have to. The DNS servers established on the market can also be divided into two types: those on which a single program is responsible for both recursive and authoritative DNS (e.g. Bind) and those which have separate components for these two tasks (e.g. PowerDNS).
By the way, in everyday administration, both recursive and authoritative name servers are generally designed with redundancy. This means that one client generally knows several recursive name servers so that it can still make queries even when one of those servers is not working.
Most domain registries provide at least two DNS servers per domain to resolve the domain’s records. There are no limits here in practice: in Linux, almost any amount of DNS servers can be configured and the number of authoritative DNS servers per domain is also unlimited.
As the explanation above shows, the domain univention.de has to have an authoritative DNS server which knows which IP address belongs to blog.univention.de. But how does a client which wants to access this website know which DNS server is responsible for the domain univention.de? This can be best understood by looking the the anatomy of a DNS query in detail. Because this shows that several DNS servers are involved with answering a query. The authoritative DNS server system is split into three levels:
The TLD servers are generally run by the domain registries of the countries involved. In Germany, for example, DeNIC runs .de. Thus before your web browser can actually open a website, behind the scenes many DNS queries are sent to different servers in a fraction of a second.
The DNS functionality described covers the standard example in everyday IT, in which a client wants to communicate with a particular server via its host name. In practice, however, there are many further situations in which DNS is used – and in the future, the number of occasions will grow still further. Some classic use cases at the current time are:
• resolving host names from the World Wide Web in web browsers
• delivering emails within domains and sub-domains
• dynamically locating particular services (Kerberos, LDAP…) in distributed environments or within modern, container-based applications
• resolving host names in local environments for internal use, for example within a company under a pseudo top-level domain like .internal
• dynamically locating particular services or devices in environments in which protocols such as Bonjour or UPnP are used
• transport encoding for connections which are always based on the host name invoked, and which return an error when the host name and the certificate name differ
Various service providers have also started using the DNS protocol to implement global solutions like Content Delivery Networks (CDN) or geographical routing. Here, when a client sends a query to a DNS server, it returns values which are near to the client, geographically. Thus, CDNs can, for example, arrange that clients in Europe get their content from European computer centers and clients in Asia from Asian computer centers.
Recursive and authoritative name servers place considerably different demands on the admins who operate them, with recursive name servers being significantly less laborious to administer. The steps needed to set up a recursive name server are always the same, regardless of the software used:
Once the admins have worked their way through this list, they normally have one or two local DNS servers available for recursive DNS. Their IP addresses can then be registered on the client systems which can then contact them.
Setting up an authoritative DNS server is significantly more complicated. There are more things to keep in mind, which we will explore in this chapter in more detail. There are a number of terms used here, which not all admins will be familiar with, or which may have more than one possible meaning. For this reason, we will start with an explanation of these terms.
Anyone who has anything to do with setting up a DNS server will regularly come across the term “zone”. They sound complicated but are actually very simple: the term “zone” in the context of DNS is used to describe the configuration of a name server for a specific domain. The term originates in the history of BIND, the first and for a long time the most widespread DNS sever system in the history of the Internet. It saves the configuration of individual domains in “zone files”.
18.104.22.168is an A record. As IPv6 builds on IPv4, and has four times as large an address space, IPv6 records in zone files are called AAAA records.
The good news it: if you understand the essential anatomy of a zone in a DNS system, you do not have to fear any large problems when operating an authoritative DNS server. The following steps need to be taken:
Now that we have explained the basics of how DNS works, we would like to tackle the question of what problems confront admins in everyday use and how they can respond properly. Problems both large and small are caused time and again by both incorrectly configured authoritative name servers and unregistered or poorly-configured recursive name servers. But do not panic: if you have the right tools, standard errors can be solved very quickly.
This chapter deals with problems in recursive DNS. These are particularly treacherous as complaints from inexperienced users that “the Internet isn’t working” can often be traced back to DNS problems. For such cases, therefore, this is the first thing to check.
There is a trick to this: if the user opens a console on Linux or cmd.exe on windows, the command ping 22.214.171.124 reveals whether the basic Internet connection is working. 126.96.36.199 is Google’s central public name server which can be counted on to react to ICMP queries (i.e. ping). If there is an error message here, then the problem is not at the level of DNS.
On the other hand, if the ping command returns echo replies, the next step is to use ping univention.de to find out if the name resolution works. If this returns an error message such as Host not found, then something fundamental is wrong (Fig. 4).
When no name server as been set up for a system, name resolution will fail for every program. The problem is mainly encountered by client computers in both the private and professional sphere. When it is not possible to open websites on a system, it is always a good idea to check the current name server records.
For Linux systems, the user can always find these in
/etc/resolv.conf. If there are no records in this file of the form “name server IP address”, then DNS records cannot be resolved. Windows clients show the DNS configuration in the TCP/IP properties of the relevant network adapter.
There are many reason for clients having no name servers configured – assuming, of course, that the client’s Internet connection works at all. The most mundane option is that the system has a statically configured TCP/IP stack, and the admin who set it up forgot to add the name servers. Then the necessary name servers need to be added to the TCP/IP configuration by hand.
It is now much more common, however, to configure the client systems dynamically via DHCP. And DHCP contains a separate field for name servers, so that it configures them automatically. A look at the configuration of the DHCP server is enough to see if this also assigns name servers.
If this is the case, the admins have further debugging to do. This is because it is probable that the client cannot reach the name server configured. Thus, the admins must then check the network connection between the client and name server, ideally directly from the system. Linux has a tool called
dig, which helps to uncover DNS server problems. It is a DNS client itself. If
/etc/resolv.conf contains, for example, the line nameserver
192.168.0.1, the command
dig univention.de @192.168.0.1 queries the entry for univention.de at this name server. The ANSWER SECTION is important in the response, which should reveal the relevant A record. If network problems are the cause of the error, the tool exits with an appropriate error message.
Should there be no such error message, things get interesting – for example if dig can reach the name server but it returns an empty reply. Then the problem is probably an incorrectly configured recursive DNS server, which, for instance, cannot reach its DNS forwarder. One cannot really set out a probably cause for all such cases though. Incorrectly configured name servers force the admins to consider the details of their configuration and their log files.
It may be possible to diagnose the problem using
dig: if the dig command above gives an error message when the local DNS server is the target but returns the correct record for the DNS server 188.8.131.52, then the problem is the recursive server. This is because when the admin explicitly specifies a name server, dig ignores the contents of
The final problem in the example is one of the most awkward problems in the context of DNS because, in the worst case scenario, end users have no remedy other than to wait. There are certainly cases in which certain host names actually do resolve to IP addresses, but these are not able to be reached. This happens often when the admins of authoritative name server responsible for a domain change its configuration.
It is important to know that DNS has a built-in expiry date for DNS records, called time to live (abbreviated as TTL). These serve primarily to improve performance: when a recursive name server knows that the TTL record of the host name blog.univention.de is valid for 24 hours, it only needs to do go through the motions of querying the root server, the TLD server and the authoritative name server once every 24 hours. The rest of the time, it saves the result in its cache. When a client requests the IP of the host name once more, it answers with the value saved in the cache. This lowers the load on the DNS system overall and leads to quicker answers for clients.
The disadvantage is that should the authoritative DNS zone of a domain change, the admins can only assume that all clients are actually using the zone as altered when the TTL has expired. And de facto, they cannot even assume that, as some operating systems add their own local DNS caching too.
Changes can only be made in such situations conditionally. When a recursive name server is under ones own control, restarting the service will normally empty the cache. However, this will only help when the recursive DNS server actually undertakes the resolution itself and does not use a forwarding server. Operating system DNS caches are also a factor, as described above. The documentation of the system used will generally include information about how the DNS cache can be emptied.
In addition: the TTL valid for an individual DNS record can be found using
dig. It is the number which is directly behind the host name queried in the ANSWER SECTION of a query (Fig. 5).
Problems with authoritative DNS are generally significantly more complex than those with recursive DNS. This is because there are a number of factors which determine the success or failure of DNS queries here.
A problem which comes up a lot is, for instance, that the contents of a primary and secondary name server differ. Both servers return valid answers, but they are different. This happens regularly when the synchronization of records between the name servers does not work. The first place the admins should look is the servers’ log data which will generally contain corresponding error messages.
Similarly, a common problem is that there seem to be records in the DNS zones, but they do not actually make certain host names resolvable. This has, above all, to do with the way in which DNS records are kept in zones – less experienced admins often make mistakes here with the syntax. If a record in a DNS zone is actually there but not available, and if a possible difference between the primary and secondary server has been ruled out, then there is nothing for it but to study the documentation of the server software so as to tackle the problem.
It is not uncommon that the wrong name server is listed for a domain on the TLD servers. In principle, admins enter the name server when they register a domain, which needs to have already had its basic configuration carried out. Most domain registries will otherwise refuse the registration straight away. Should zones be transferred from one authoritative DNS server to another, the name server registration at the registry for this domain also needs to be changed. It is not enough to only change the NS records on the name servers themselves. As otherwise, recursive name servers will be forwarded to the old name servers by the TLD servers.
The final chapter of this article is dedicated to the question of how UCS deals with the topic DNS, and what functionality is available out of the box. As a basic principle, UCS treats DNS as what it is: an elementary component of networks. Thus it tries to process the majority of the DNS configuration automatically, without bothering the administrator.
In plain language, this means that DNS servers always run alongside every UCS domain controller and any secondary controller (these are called directory nodes from UCS 5.0 on). The principle is that they get their configuration from OpenLDAP, the central directory service, which also belongs to UCS. When UCS is used as a domain controller, DNS plays a particularly large role: as already mentioned, it is then necessary to have correct DNS records for specific servers and services, as otherwise, for instance, the authentication of users and single sign on will no longer work. Reverse lookups, i.e. resolving PTR records has to function. So after the admins have configured it, UCS takes care of these records itself. (Fig. 6)
In domains compatible with Active Directory, UCS also supports the DNS components of Samba 4, which can then be used as the basis for name servers instead of OpenLDAP. In such setups, our own tool makes sure that the DNS records from Samba get to OpenLDAP and vice versa. UCS also operates a DHCP server itself (which requires some configuration, whereas DNS is largely automatically configured). Because of this, in the standard configuration at least, it is ensured that clients know the correct DNS server.
On the other hand, UCS is not designed to be used as a general recursive or authoritative name server for specific domains. Ideally, matching name servers are set up to complement UCS before its installation, to be used as “forwarding servers” in UCS. Then when clients make DNS queries which the name server integrated in UCS cannot answer, it forwards them on the externally configured server. Alternatively, UCS can be configured so that it takes over the connections to the DNS root server itself.
The admins do not have to operate external DNS servers themselves, by the way. For example, one could use the name server which are generally offered by the domain registry. These can generally be managed via convenient GUIs (Fig. 7).
We hope that you enjoyed this introduction to DNS and found it somewhat helpful. Got any questions, suggestions or additions? We’re looking forward to our comments!
Martin Loschwitz is a geek, Debian developer and a Cloud Platform Arcitect at Drei Austria where he deals a lot with privad cloud environments and Open Stack. Furthermore, he's a freelance journalist who's been active in the IT setting for more than 20 years. In his articles, he mainly writes about the topics Open Stack, software-defines storage and software-defined networking.
The longer that i read about UCS as it has been updated the better it seems to be getting.
I have been working on matrix.org for a little over a year and testing it on different OS platforms and have yet to try it with yours but i think it’ll make things a lot easier to deploy especially now with more workers trying to work from home and the security nightmare of managing so many systems in constantly changing network environments.