One of the most beautiful, powerful and robust protocols in the network world is DNS. Unfortunately, it is sometimes used incorrectly. With this article I hope to make clear why DNS is important and to provide some clarity about the significance of DNSSEC.
What is DNS?
DNS stands for Domain Name System, a system that translates domain names into objects/data. Compare it with our daily use of addresses. You want to visit something, for example Google’s headquarters. To get there we need the location, which are the coordinates 37.3861 ° N and 122.0839 ° W. Fortunately we have developed something easier: the address (1600 Amphitheater Parkway in Mountain View, California, United States). You need the address to arrive at a location. An address takes you to a location by giving a relevant reference at different levels (Country, City etc). On networks we also have (IP) addresses, in combination with routes and via the underlying MAC addresses an IP package can find its goal. Because the content and distinction of all these addresses does not work well, DNS has been developed.
The ARPANET, the forerunner of the internet, was invented in the 1970s. People worked with (ip) addresses on this. To also use names, a file (host.txt) was included in which all computers of the ARPANET were named. SRI-NIC maintained this file and took care of the distribution (they offered it for download). As the ARPANET grew, the file became larger and larger, which quickly resulted in performance and stability problems with the connections and servers available at that time. Not everyone had the correct version of the host.txt file available on time. Because there was no (hierarchical) structure in the naming of computers, duplicate names quickly developed. In 1983, Paul Mockapetris first described DNS in RFCs 1034 and 1035. Subsequently, a large number of updates followed.
When developing DNS, a number of principles have always been maintained that still guarantee the power of DNS today.
Distributed globally, data is maintained locally but can be retrieved worldwide. There is not one computer that has all DNS data. Any device can ask questions to the DNS. External data is cached to improve performance.
Loose Coherency. This means that the DNS system is always in an (internally) consistent state by recording version numbers for parts of the DNS (zones). The version number is incremented with every change. Changes to the master database (zone) are replicated according to the timing set by the administrator. Data in caches also run according to timeouts set by the zone administrator.
Scalable, no database size limit, no limitations in the number of queries that can be done. This through automatic distribution via master, slave and cache systems.
High availability, redundant, data has been copied to multiple servers. Clients can make contact with both master and slave servers. Clients will use the local cache. As long as someone can give an answer there will be an answer.
Dynamic, it is possible to dynamically update the (master) database. Every update of the master ignores replication.
Following the above principles has led to a number of concepts that we see in the design of DNS.
DNS is hierarchical, protecting scalability. For example, a Fully Qualified Domain Name (FQDN) looks like this: “medium.com.” Also note the closing point. An FQDN offers references to different types of objects.
You can display domain names in a tree. Every point in the name offers the possibilities for further branches. DNS has no restrictions on the number of branches. A domain name is a “namespace”. Example: everything under .com. is the .com domain. everything under slideshare.net. is it slideshare.net. domain within the .net domain.
Within a domain, administrators can assign sub domains to other computers. Administrators can also assign the responsibility for a subdomain to someone else, but that is not mandatory.
Domains are administrative zones for which the domain administrator is responsible. This responsibility is assigned from the higher level.
DNS Web Servers.
There are 3 roles to describe DNS servers, master (the main server of a zone on which you publish changes), slave (replicates from the master) and caching/forwarders. The master and slave roles are “Authoritative” roles, these make DNS data available to the network as part of the large global database. Search the caching or forwarder role in the global database for end users. Most ISPs make forwarders available to their customers, in addition there are various “open” alternatives such as the DNS servers of Google or OpenDns.
The DNS protocol records how replication between master, slave and the cache works. This makes it possible for different companies and institutions to develop DNS servers that can work together. It is therefore perfectly possible, for example, to have a PowerDNS Master and run ISC and Nominum on the slave servers while you use Microsoft DNS for searching (forwarder).
A resolver will query the DNS system on behalf of an application. In this process on many systems (including Windows 2008 R2) the principle of the host.txt file from the 70s can still be found, this is the first to look quickly. If there is no answer in the host file, this is passed on to a resolver/caching DNS server (1). If the person does not yet know the answer, he will request the root (“.”) (2). The root will indicate that it has delegated responsibility for the requested domain to another computer (3). The resolver will then contact the underlying zone again and request it again (4). Via an additional delegation (5) the resolver eventually ends up at an authoritative server (master or slave) (6) and receives the answer (7) that is given to the application (8).
DNS can provide answers to many different questions, for which different types of records have been established. Often used is the Address record, in which an IP address is stored.
Record type Description Example.
A IP Address www.google.com . A 126.96.36.199
CNAME Alias for www.google.com . CNAME www.google.com
NS Nameserver www.google.com . IN NS a.ns.google.com
MX Mail Exchange google.com. IN MX filter1.google.com
PTR Pointer 188.8.131.52. PTR www.google.com
SOA State of Authority google.com. IN SOA a.ns.google.com domains.google.com 9012052100 3600 3600 704800 3600
TXT Text google.com. IN TXT “v = spf1 a: mail.google.com/27-all”
For transporting DNS questions and answers, the UDP protocol was initially chosen, instead of the current TCP. Nowadays, TCP is also supported by most DNS servers, especially to optimally support IPv6. In addition, in contrast to UDP, TCP is a session-based protocol, where it is significantly more difficult to apply DNS spoofing. Because no session statuses have to be kept at UDP, it is considerably lighter for the servers, but with the performance that servers can deliver nowadays, the extra burden of TCP is almost negligible.
The great thing about DNS is that as long as at least one authoritative server is functional, the full principle of DNS is still active. By using different operating systems and DNS software on different networks, and in different data centers for master and slave servers, it is not difficult with DNS to achieve 100% availability. If a complete malfunction occurs at the master and slave servers, there is still a good chance that the DNS cache of different providers can still provide customers with answers. Many services, such as e-mail, respond with a definitive error if the DNS does not work, while the failure of an e-mail server only leads to a delay.
DNSSEC is a secure successor to DNS that is already supported by the majority of servers and clients. With DNSSEC, a DNS response is provided with a digital signature that can be used to check whether the response comes from a legitimate source. DNS clients with DNSSEC support require a DNSSEC response if DNSSEC is activated for the domain in question, if the domain does not yet have DNSSEC, they accept “normal” DNS responses. DNSSEC prevents DNS spoofing (also known as the Kaminsky attack). After the danger of spoofing was discovered in 1990, the protocol was written in 1995 and finally recorded in RFC2535 in 1999. Finally, an improved version of DNSSec was recorded in 3 RFCs 4033, 4034, 4035 in 2005, after which Sweden (.SE) was the first to activate DNSSEC in October 2005.
The biggest advantage of DNS Sec is of course the security and control of DNS answers. In addition, DNSSec “fans” also frequently state that DNS, with the DNSSEC extension, can also be used for distributing and checking all kinds of other data such as server certificates (SSL). This extension is called DANE meaning “DNS-based Authentication of Named Entities”.
DNSSec makes DNS a more complex operation, where a minor error or failure can cause your domain to temporarily not exist. DNS loses some of its robustness, so it is the consideration of security versus availability.
DNSSEC advocates secure domains as a trust relationship that is more reliable than a Certificate Authority. The fact is, however, that most TLDs have never done 100% reliable checks on the identity of all domain owners. With the introduction of IDN (Internationalized Domain Names) and allowing non-ASCII characters in domain names, it can become difficult for the end user to recognize the difference between the real website of, for example, a bank and a fake site. With DANE it even becomes possible to put a valid certificate on the net site. DANE, is a protocol for securely publishing public keys and certificates. In addition, this standard builds on the cryptographically secured DNS infrastructure that is installed with DNSSEC.