DNSSEC

Every user and every presence on the World Wide Web has a personal, unique IP address, con­sist­ing 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 re­spon­si­ble for name res­o­lu­tion, making it one of the most important services of IP-based networks. Con­sist­ing of various name servers (known as DNS servers), it trans­lates human-friendly text names into IP addresses and vice versa, enabling the client to establish contact.

But this com­mu­ni­ca­tion 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 Ex­ten­sions (DNSSECs) are concerned with various internet standards that extend the domain name system to source iden­ti­fi­ca­tion and, in doing so, ensure the au­then­tic­i­ty and integrity of the data. After the initial DNSSEC version from 1999 turned out to be un­suit­able for larger networks, it was a few years until the ex­ten­sions 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 tech­nol­o­gy was applied to the root level of the internet, namely on the 13 root name servers that are re­spon­si­ble for the name res­o­lu­tion of top-level domains (.com, .co.uk, etc.)

DNSSEC is based on a public key cryp­tosys­tem, an asym­met­ric en­cryp­tion method in which the two parties involved exchange a pair of keys con­tain­ing a public key and a private key, as opposed to one, shared, secret key. The private key carries all pieces of DNS in­for­ma­tion, known as resource records, and a unique digital signature. Through the public key, the clients can verify this signature and so the au­then­tic­i­ty of the source can be confirmed.

Every name server in the Domain Name System is re­spon­si­ble for a certain zone. In this in­di­vid­ual 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 in­te­grat­ed as a DNSKEY resource record in the zone file and is used to make sure that every single piece of in­for­ma­tion within the zone is given a signature. This creates RRSIG resource records, which are delivered in ac­com­pa­ni­ment to the resource record in question. This com­bi­na­tion remains intact, re­gard­less of whether it’s stored in the cache or trans­ferred 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 man­age­ment process and create a chain of trust, a syn­tac­ti­cal­ly 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 au­then­tic­i­ty 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 re­triev­ing in­for­ma­tion from name servers. They act as either iterative or recursive resolvers during requests. In the first case, the resolver receives either the requested in­for­ma­tion 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 re­cur­sive­ly, 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 in­for­ma­tion isn’t available in the database, then the complete re­spon­si­bil­i­ty of the address res­o­lu­tion 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 con­ven­tion­al clients like web browsers and are also referred to as stub resolvers.

In order to utilize DNSSEC, you’ll need a val­i­dat­ing resolver that can evaluate the ad­di­tion­al in­for­ma­tion generated. For this, the resolver has to support the protocol extension known as the Extension Mech­a­nisms for DNS (EDNS), because this is the only way that val­i­da­tion can be activated in the DNS header.

Because of the complex con­di­tions involved, making DNSSEC available to everyone is proving difficult; the tech­nol­o­gy 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 en­cryp­tion and initiate pro­ce­dures. Users have no influence over whether a website is protected through DNSSEC sig­na­tures and need a val­i­dat­ing resolver. So to make use of this DNS security pro­tec­tion, 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 sig­na­tures. In any case, you should be aware that the DNSSEC only au­tho­rizes name res­o­lu­tion; the data trans­mit­ted receives no pro­tec­tion. This means it’s essential to combine this tech­nol­o­gy with encrypted trans­mis­sion protocols like TSL. The following problems are also possible and can cause delays in the ac­cep­tance of your DNS security tech­nol­o­gy: 

• 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 val­i­dat­ing DNS resolver, it’s possible that an attack can be suc­cess­ful between the client and the name server of the provider, even if this DNSSEC verifies the signature to be genuine.

In other vul­ner­a­bil­i­ties, 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.