DNSSEC: internet standards for authenticated name resolution

Every user and every presence on the World Wide Web has a personal, unique IP address, consisting of several numbers. But this IP address isn’t very human-friendly, so when users visit a website or send an email, a more practical domain name like ionos.com is used instead of the IP address. This is where the Domain Name System (DNS) comes into play. It’s responsible for name resolution, making it one of the most important services of IP-based networks. Consisting of various name servers (known as DNS servers), it translates human-friendly text names into IP addresses and vice versa, enabling the client to establish contact.

But this communication between name server and client brings with it a great security risk; since the identity of the sender can’t be checked, the recipient can’t determine whether the incoming DNS response has actually come from the server that was requested. If an attacker has now switched between name server and client, then it can assign a false IP address to a recipient. DNSSEC was developed to protect the DNS against this threat.

The Domain Name System Security Extensions (DNSSECs) are concerned with various internet standards that extend the domain name system to source identification and, in doing so, ensure the authenticity and integrity of the data. After the initial DNSSEC version from 1999 turned out to be unsuitable for larger networks, it was a few years until the extensions for DNS security were finally published in the three RFCs (Requests for Comments) RFC 4033, RFC 4034, and RFC 4035 in 2005, making DNSSEC standard practice in the US. In 2010, this technology was applied to the root level of the internet, namely on the 13 root name servers that are responsible for the name resolution of top-level domains (.com, .co.uk, etc.)

DNSSEC is based on a public key cryptosystem, an asymmetric encryption method in which the two parties involved exchange a pair of keys containing a public key and a private key, as opposed to one, shared, secret key. The private key carries all pieces of DNS information, known as resource records, and a unique digital signature. Through the public key, the clients can verify this signature and so the authenticity of the source can be confirmed.

Every name server in the Domain Name System is responsible for a certain zone. In this individual zone file, the DNS stores a complete list of all resource records, which describe its zone. For this reason, every name server has its own zone-signing key, allowing secure resource records to remain private and protected. The public part of the zone-signing key is integrated as a DNSKEY resource record in the zone file and is used to make sure that every single piece of information within the zone is given a signature. This creates RRSIG resource records, which are delivered in accompaniment to the resource record in question. This combination remains intact, regardless of whether it’s stored in the cache or transferred to another name server. The final part of its journey sees it end up at the requested client, who can validate the signature with help of a DNS resolver and the public key.

To simplify the key management process and create a chain of trust, a syntactically identical key-signing key (KSK) exists alongside the zone-signing key, which is there to confirm the identity. This key-signing key is simply there to ensure the authenticity of the zone-signing key in question. A hash value of the signature key is stored in a DNS record of the parent zone as a trusted key, meaning the resolver can just be given access to the public key for the uppermost zone – the root level.

DNS resolvers are software modules of clients that are capable of retrieving information from name servers. They act as either iterative or recursive resolvers during requests. In the first case, the resolver receives either the requested information or a reference to be passed on to the next name server. It continues in this manner until it has resolved the address. Resolvers who function recursively, on the other hand, send a request to their assigned name servers in the local network or on the provider’s network. If the requested information isn’t available in the database, then the complete responsibility of the address resolution now falls on the shoulders of this assigned name server, which in turn sends iterative queries onwards until the case is solved. Recursive resolvers are typical for conventional clients like web browsers and are also referred to as stubresolvers.

In order to utilize DNSSEC, you’ll need a validating resolver that can evaluate the additional information generated. For this, the resolver has to support the protocol extension known as the Extension Mechanisms for DNS (EDNS), because this is the only way that validation can be activated in the DNS header.

Because of the complex conditions involved, making DNSSEC available to everyone is proving difficult; the technology has to be supported on both the side of the we presence’s provider as well as the visitor side. Domain owners have to presume that the registrar supports the encryption and initiate procedures. Users have no influence over whether a website is protected through DNSSEC signatures and need a validating resolver. So to make use of this DNS security protection, you need to either download and operate a private resolver like Bind, use a browser extension like Mozilla Firefox’s DNSSEC Validator, or search for a provider who checks DNSSEC signatures. In any case, you should be aware that the DNSSEConlyauthorizes name resolution; the data transmitted receives no protection. This means it’s essential to combine this technology with encrypted transmission protocols like TSL. The following problems are also possible and can cause delays in the acceptance of your DNS security technology: 

• Because of the increased strain placed on the name server, it can be easier for denial of service attacks (which stop your service from working) to take place.
   
• The DNSSEC chain of trust is in more danger of being breached because public keys are shared over the domain name system.
   
• Without a validating DNS resolver, it’s possible that an attack can be successful between the client and the name server of the provider, even if this DNSSEC verifies the signature to be genuine.

In other vulnerabilities, for example with what’s known as DNSSEC walking, in which the attacker reads out the full content of a DNSSEC signature zone, there’s already been a response in updates. Newer resolver versions name their different resource records with a hash value rather than a clear text label.