The Domain Name System Security Extensions (DNSSEC or DNS Security Extensions) is a set of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks.
DNSSEC provides DNS resolvers origin authentication of DNS data, authenticated denial of existence and data integrity but not availability or confidentiality.
DNSSEC authenticates DNS using digital signatures based on public key cryptography. With DNSSEC, it's not DNS queries or response that are signed but rather the DNS data itself is signed by the owner of the data.
Before we dive into DNSSEC, it's important to understand what DNS is and why we need DNSSEC.
What is Domain Name System (DNS)?
The Domain Name System (DNS) is a hierarchical and decentralized naming system for computers, services and other resources that connect to the Internet. DNS associates information with domain names. The most common use is to translate human readable domain names (like icann.org) to the numerical IP address used to locate and identify services and devices with underlying network protocols.
DNS delegates responsibility to the authoritative name servers of each domain who can assign and map domains to IP addresses. This creates a distributed, fault-tolerant service that isn't centrally hosted.
DNS also defines the DNS protocol, which is a specification of data structures and data exchanges used in the DNS.
How Does DNS Work?
The Internet depends on DNS functioning correctly. Every web page, email sent and picture received relies on DNS to translate a human friendly domain name to an IP address used by servers, routers and other networked devices.
When you use the Internet, it all starts with DNS. Imagine you enter example.com into your browser. The browser will use the stub resolver, part of its operating system, to translate the website's domain name into an IP address.
A stub resolver is a simple DNS client that relays requests for DNS data to the more complicated recursive resolver. Many network operators run recursive resolvers for their customers or the public at large including Google, OpenDNS and Quad9.
Once the recursive resolver has your request, it then sends its own DNS requests to multiple authoritative name servers. All domain's DNS data is stored on name servers on the Internet. Some organizations even run their own, but most will outsource this function to a third-party like a registrar, Internet service provider or web hosting company.
What is a DNS Zone?
The DNS is broken up in many different zones. Each zone manages a distinct area in the DNS namespace and is managed by a specific organization or administrator.
Think of a DNS zone as the administrative space that allows fine grain control over DNS components, such as their name servers. The domain namespace is a hierarchical tree with the DNS root domain at the top, which controls all other DNS zones. Each DNS zone starts at a domain within the tree and can extend down into subdomains, allowing one entity to control multiple subdomains.
An example branch in the tree might be as follows:
- Root DNS zone
- Com DNS zone
- Upguard DNS zone
Keep in mind that DNS zones are not necessarily associated with a single domain name or single DNS server. There are situations where multiple subdomains or multiple zones can exist on the same server. Zones are strictly to delegate control and not necessarily physically separated.
What Information is Stored in the DNS Database?
The most common records stored in the DNS database are the Start of Authority (SOA), IP addresses (A and AAAA), SMTP mail exchangers (MX), name servers (NS), pointers for reverse DNS lookup (PTR) and domain name aliases (CNAME).
Why is DNSSEC Important?
DNS is the phone book of the Internet, it tells your computer where to send and retrieve information. Unfortunately, DNS was created in the 1980s when the Internet was small and security was not a main concern. This means that DNS will accept any address it is given by default no questions asked. This can lead to various cyber attacks and poses a real cybersecurity threat.
When a recursive resolver sends a request to a name server, the resolver has no way of verifying the authenticity of the response. It only checks the response appears to come from the same IP address as the original request was sent to.
This is a poor form of authentication because the source IP can be forged or spoofed. This allows attackers to masquerade as the authoritative name server the resolver originally requested by spoofing a response that appears to come from them.
In simple terms, an attacker can redirect a user away from where they intended to go without the end user realizing.
This problem has been compounded by the fact that recursive resolvers cache DNS data to speed up resolution. This means that if the stub resolver on your device asks for DNS data the recursive resolver already has in its cache (saved), it can answer immediately without requesting an answer from the name server.
While this provides speed and efficiency benefits, it has a big downside. If a cyber attack sends forged DNS responses that is accepted by a recursive resolver, the resolver is said to have a poisoned cache, also known as DNS Cache Poisoning. This means any user who interacts with this resolver will be sent fraudulent DNS data until the time-to-live (TTL) expires.
DNSSEC is an attempt to add additional security to DNS while remaining backwards compatible.
DNSSEC Resource Record Glossary
Before we outline how DNSSEC works, it's important to understand the new DNS resource record types were created or adapted for DNSSEC usage:
- RRSIG (resource record signature): Contains the DNSSEC signature for a record set. DNS resolvers verify the signature with a public key, stored in a DNSKEY record.
- DNSKEY: Contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records.
- DS (delegation signer): Holds the name of a delegated zone and references a DNSKEY record in the sub-delegated zone. This is placed in the parent zone along with the delegating NS records, this is often the Top-Level-Domain (TLD) of your domain.
- NSEC (next secure record): Contains a link to the next record name in the zone and lists record types that exist for the record's name. DNS resolvers use NSEC records to verify the non-existence of a record name and type as part of DNSSEC validation.
- NSEC3 (next secure record version 3): Contains links to the next record name in a zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 record's own name. These are used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation. They are similar to NSEC records but use cryptographically hashed record names to avoid the enumeration of the record names in a zone.
- NSEC3PARAM (next secure record version 3 parameters): Authoritative DNS servers use this record to calculate and determine which NSEC3 records to include in responses to DNSSEC requests for non-existing names/types.
How Does DNSSEC Work?
When DNSSEC is used, each answer to a DNS request contains an RRSIG DNS record, in addition to the record type that was requested. The RRSIG record is a digital signature of the requested DNS data. The digital signature is verified by locating the correct public key that is found in the DNSKEY. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non-existence of any request. This is also known as authenticated denial of existence.
The delegation signer (DS) is used in the authentication of DNSKEYs by using what is called a chain of trust. NSEC and NSEC3 also serve the purpose of providing robust resistance against spoofing.
The chain of trust starts with a set of verified public keys for the DNS root zone which is the trusted third-party. Domain owners generate their own public key/private key pair and upload them using their DNS control panel at their domain-name registrar, which in term pushse the keys via secDNS to the zone operator (for example Verisign for the com zone) who signs and publishes them in the DNS
This prevents resolvers from caching forged or manipulated DNS data and prevents cache poisoning.
In short, DNSSEC provides two security features to DNS:
- Data origin authentication: Allows a resolver to cryptographically verify data came from the zone requested.
- Data integrity protection: Allows a resolver to know that the data hasn't been modified in transit and was originally signed by the zone owner's private key.
These two security features all any recursive resolver to look up data in the zone and retrieve the zone's public key which is then used to validate the authenticity of provided DNS data. Resolvers then confirm the digital signature received matches what they expect and return it to the end user. If the signature is not valid, the resolver assumes a cyber attack, discards the data and returns an error.
How Do Resolvers Know When to Trust DNSSEC Keys?
Each zone publishes its public key which a resolver can use to validate the data in the zone. The integrity of the public key can be determine like other data in the zone because it too is signed. The difference is that its public key is signed by its parent zone's private key.
For example, the UpGuard.com zone public key is signed by its parent, the com zone. Each zone parent is responsible for vouching for the authenticity of its child zone's public key. You can follow this logic all the way up the DNS tree to the DNS root zone, which is responsible for all children. By definition, it has no parent to sign its key and is innately trusted.
The DNS root zone is the starting point for validating all DNS data, so if a resolver trusts the DNS root zone's public key, it trusts all top-level zones signed by its private key, such as the public key for the com zone.
And because the resolver trusts the public key for the com zone, it trusts the public keys that have been signed by its private key such as the public key for UpGuard.com.
This is the chain of trust that we touched on above. The first public key of a chain of trust is called the trust anchor. When DNSSEC was originally designed, there was only one trust anchor (the DNS root zone). These days trust anchors are typically obtained from the operating system or from another trusted source. Resolvers trust the public keys of trust anchors implicitly and do not check further up the tree.
Most resolvers only have one trust anchor for each zone (com, net, org etc.), which allows them to build a chain of trust to any location in the DNS name space as long as each zone in the path is signed.
How are DNSSEC Keys Replaced?
In order to allow for replacement keys, a key rollover scheme is needed. This involves first rolling out new keys in new DNSKEY records alongside the existing keys. Then when it is safe to assume the time-to-live (TTL) values have caused the caching of old keys to pass, the new keys are used.
Once the caching of old keys have expired, the old DNSKEY records are deleted. This process becomes more complicated for keys that are used as trust anchors but this affects very few people.
There are two different uses for DNSKEY records:
- Key signing keys (KSK): Used to sign other DNSKEY records.
- Zone signing keys (ZSK): Used to sign other records.
ZSKs are under the complete control and use of one particular DNS zone can be switched more easily and often. As a result, ZSKs can be shorter than KSKs and offer a similar level of protection while reducing the size of records.
Contrast this with KSKs, which require the delegation signer (DS) record to be transferred to the parent zone and published there. DS records use a message digest of the KSK instead of the complete key to keep the size fo the records small. This isn't a problem for many zones but is helpful for zones such as the com domain, which is very large.
What Does DNSSEC Protect Against?
While the primary concern of DNSSEC is to prevent the cyber threat of DNS spoofing, resulting in users being directed to the wrong place, DNSSEC provides the additional benefit of protecting text records (TXT) and mail records (MX). DNSSEC has also been used to bootstrap other cyber security systems that publish cryptographic certificates stored in DNS such as Certificate records, SSH fingerprints, IPSec public keys and TLS Trust Anchors.
That said, DNSSEC, unlike SSL certificates, do not provide confidentiality of data. DNSSEC responses are authenticated but not encrypted. Nor does DNSSEC protect against cyber attacks like distributed denial of service attacks (DDoS attacks).
Remember, the main protection DNSSEC provides is it prevents third-parties from being able to forge records and guarantees a domain's identity by preventing:
- DNS Cache Poisoning: A form of man-in-the-middle attack where attackers flood a DNS resolver with false DNS information. Sometimes these attacks can get a match by the law of large numbers and plant a false result into the cache of the DNS resolver. The DNS resolver then provides this erroneous or malicious web address to anyone seeking that website until the time-to-live (TTL) expires.
- False zones: DNSSEC also protects against malicious DNS attacks that exploit the DNS system and provide phony results for zones that don't even exist, essentially exploiting gaps between zones. DNSSEC secures the entire zone and provides mechanisms to prevent gap exploitation in unsigned zones. This is also known as the authenticated denial of existence.
Other standards are used to secure bulk data sent between DNS servers, such as a DNS zone transfer. Even with DNSSEC, some users will still make false assumptions about DNS names such as assuming a company's common name plus ".com" is always its domain name.
DNSSEC cannot protect against false assumptions, it can only authenticate the data is truly from or not available from the domain owner.
Why Doesn't Everyone Use DNSSEC?
It is widely accepted that securing DNS is a critically important part of securing the Internet as a whole but the deployment of DNSSEC has seen several difficulties:
- Backwards compatibility: The need to design a backward compatible standard that can scale to the size of the Internet is extremely difficult
- Zone enumeration prevention: An important part of DNSSEC is the ability to authoritatively assert that a given name does not exist.
- Deployment difficulties: Deploying DNSSEC across a wide variety of DNS servers and resolvers takes time.
- Ownership disagreements: There have been disagreements of over who should own the top-level domain root keys.
- Perceived complexity: It has been hard to overcome the perceived complexity of DNSSEC and DNSSEC deployment.
DNSSEC Summary
DNSSEC forms a fundamental part of widespread Internet security or at least it would if it was widely adopted. Now it needs to be specifically enabled by recursive resolvers and by domain name owners.
Users should have assurance that when they type in a domain they end up at their desired destination and that is exactly what DNSSEC ensures.
How UpGuard Can Help You Monitor DNSSEC
UpGuard helps companies like Intercontinental Exchange, Taylor Fry, The New York Stock Exchange, IAG, First State Super, Akamai, Morningstar and NASA protect their information security and prevent data breaches.
Whether your organization has one domain or thousands, our platform can monitor your organization's and its vendor's websites for DNSSEC, typosquatting and susceptibility to man-in-the-middle attacks and other vulnerabilities. UpGuard BreachSight can also help prevent data breaches and data leaks of sensitive data and personally identifiable information (PII), protecting your customer's trust through cyber security ratings and continuous exposure detection.
