The Domain Name System (DNS) is the backbone of the internet, providing a way to translate domain names like “example.com” into IP addresses like 192.0.2.1 that computers use to route traffic. However, DNS was not originally designed with security in mind. DNS Security Extensions (DNSSEC) aim to address this by adding security features like digital signatures to DNS. This allows validating DNS responses to ensure they have not been manipulated by attackers.
DNSSEC works by creating a chain of trust originating from the root DNS servers. DNS responses are digitally signed using public-key cryptography. Validating resolvers can follow the chain of trust to verify signatures all the way back to a trusted root. This protects against attacks like DNS cache poisoning or domain hijacking by allowing altered DNS data to be detected.
In this article, we will demystify DNSSEC and cover:
- The problems DNSSEC tries to solve
- How digital signatures and public-key cryptography work
- The chain of trust model used by DNSSEC
- Deployment status and adoption challenges
- Implementation in major environments like BIND
- Pros and cons of DNSSEC
- Alternatives like DNS-over-TLS and DNS-over-HTTPS
Properly implemented, DNSSEC significantly improves DNS security and the integrity of the global internet infrastructure. While adoption challenges remain, education and implementation efforts continue to spread DNSSEC protections.
Problems with Traditional DNS
The original DNS protocol has well-known security weaknesses that DNSSEC aims to address:
No Authentication of Responses
DNS uses UDP and allows open recursive resolvers. This makes it vulnerable to spoofed responses from malicious actors. There is no way to authenticate legitimate DNS data.
Cache Poisoning
An attacker can inject false DNS records into the cache of a vulnerable resolver to redirect traffic or cause other havoc. This is known as DNS cache poisoning.
Lack of Integrity Checks
There are no mechanisms in place to prevent manipulation of DNS records in transit. This enables malicious tampering or impersonation.
Domain Hijacking
Without authentication, an attacker can hijack a domain by simply creating DNS records that point to their own servers. DNSSEC makes this much harder.
These weaknesses enable various attacks like pharming, DNS-based malware distribution, man-in-the-middle attacks, and more. Billions of devices rely on DNS, so securing it is crucial for the health of the internet.
Digital Signatures and Public-Key Cryptography
DNSSEC secures DNS through the use of digital signatures and public-key cryptography. This allows validators to cryptographically verify the authenticity and integrity of DNS responses.
Digital Signatures
A digital signature is a mathematical scheme that lets someone prove the authenticity and integrity of data. Signatures are generated by the owner of some private data. Third parties can then mathematically verify signatures without needing access to the private data itself.
Public-Key Cryptography
Public-key cryptography uses key pairs made up of a private key and a public key. Data encrypted with the private key can only be decrypted with the corresponding public key. This allows the public key to be widely shared for validating signatures, without compromising the private key used to create the signatures.
Signing Zone Data
In DNSSEC, zone operators digitally sign their zone data using the private key for that zone. This data plus the signature is distributed in DNS responses. Recursive resolvers can validate the signature using the zone’s public key.
These cryptographic principles are the foundation for securing DNS data and establishing trust.
Chain of Trust Model
DNSSEC establishes a hierarchy of trust that originates from the DNS root zone. Each zone is responsible for signing its own DNS records and publishing its public key. Parent zones sign their children’s public keys. This creates a chain of trust that can be followed to verify keys and signatures.
Root Zone
The root zone is operated by IANA/ICANN and is the ultimate trusted starting point. The root public key, known as the trust anchor, is distributed out-of-band on operating systems and software. All DNSSEC validation begins by checking root zone signatures.
Top-Level Domains (TLDs)
TLD operators (.com, .net, etc) sign their zone data with their private key. The root zone signs the public keys of TLDs, establishing a chain of trust.
Lower-Level Zones
This continues down to lower-level zones that inherit trust from their parent zone. For example, example.com trusts keys signed by .com, which chains up to the root.
With this model, anyone can follow the chain of signatures up the DNS hierarchy until reaching a trusted root anchor. This allows validating the origin and integrity of all DNSSEC-signed responses.
DNSSEC Record Types
DNSSEC introduces several new resource record types that are used to publish public keys, signatures, and other metadata:
- DNSKEY – Contains the public key used to verify RRSIG records.
- RRSIG – Contains the digital signature for a resource record set.
- DS – Delegation signer. Links a child zone to its parent. Contains the child’s key hash.
- NSEC/NSEC3 – Proves non-existence of names and prevents zone walking.
- CDNSKEY – Cryptographic keys for validating CDS and CDNSKEY records.
- CDS – Child DS. Provides a hash of the DS record downstream.
These record types allow building the chains of trust used in DNSSEC.
Deployment Status
DNSSEC adoption has been gradually increasing but still faces some challenges:
- The root zone was signed in 2010. This was a major milestone.
- As of 2022, about 93% of TLDs are signed.
- Roughly 30% of all domains are DNSSEC-enabled.
- Adoption varies greatly by region. Europe has high deployment around 60-80%. The U.S. is lower at 10-20%.
Some obstacles to full adoption include:
- Increased complexity to manage keys and signatures.
- Cost overhead for signing operations and cryptography.
- Lack of support from some registrars and DNS providers.
- Perception that attacks like pharming are no longer a threat.
However, adoption by major providers like Cloudflare and increasing automation of DNSSEC processes are helping drive up use. Support at the registrar level also continues to improve.
DNSSEC Implementation
Implementing DNSSEC involves both signing a DNS zone and enabling validation by recursive nameservers:
Signing Zone Records
To sign a zone, the zone operator must:
- Generate a cryptographic key pair for the zone. The private key is closely guarded.
- Use the private key to digitally sign the zone file contents. This generates RRSIG records that get distributed with the zone data.
- Add DNSKEY records containing the zone’s public key.
- Configure a parent zone (like the TLD) to sign the DS record containing the child zone’s key hash.
Proper key management, key rollovers, and signature refreshing are also critical tasks.
Validating Signatures
Validating resolvers must perform several checks on DNS responses:
- Verify the zone’s DNSKEY against the parent’s DS record. Walk up the trust chain.
- Validate the RRSIG signature for the record set using the DNSKEY.
- Ensure signatures have not expired.
- Verify responses using NSEC/NSEC3 records.
- Ultimately anchor to a trusted root key.
With validation enabled, signed responses are cryptographically verified before acceptance.
DNSSEC in BIND
BIND is the most widely used DNS server software. Enablement of DNSSEC features is straightforward:
Signing a Zone
Include these options in named.conf:
dnssec-policy standard {
keys {
ksk lifetime 365d algorithm rsasha256;
zsk lifetime 90d algorithm rsasha256;
}
}
zone example.com {
type master;
file "db.example.com";
dnssec-policy standard;
};This handles key generation, signing, refreshing, etc. Keys are stored in K* files.
Validating Responses
Add this server clause:
server 192.0.2.1 {
dnssec-validation auto;
};This configures BIND to check DNSSEC signatures automatically.
BIND provides robust DNSSEC support with configurable policies. Validation is enabled by default since version 9.11.
Pros of DNSSEC
Key benefits of DNSSEC include:
- Mitigates attacks like cache poisoning, domain hijacking, man-in-the-middle, etc.
- Improves integrity and authenticity of DNS data.
- Reduces risks associated with malicious DNS manipulation.
- Reliable framework for establishing trust rooted in DNS root zone.
- Utilizes most secure aspects of cryptography like signing algorithms and key sizes.
- Policies flexibly managed through TTLs, rollover timing, zone propagation, etc.
- Gradual deployment possible alongside traditional DNS.
Cons of DNSSEC
Some downsides to DNSSEC:
- Increased complexity for administrators to manage keys, signatures, rollovers, etc.
- Additional storage space and bandwidth required for larger responses.
- Cost overhead for certificate authorities, signing operations, key generation, etc.
- Changes required to DNS server software for signing zones and validating responses.
- Potential for outages if signatures fail validation when keys roll over.
- Does not address vulnerabilities around callee authentication or metadata privacy.
Alternative Security Approaches
Other mechanisms also exist for securing DNS beyond just DNSSEC:
DNS over TLS
Encrypts DNS transport between stub and recursive resolvers using TLS. Provides confidentiality and integrity. Does not secure last mile to authoritative.
DNS over HTTPS
Uses HTTPS instead of UDP for DNS queries. Adds TLS encryption and utilization of existing HTTPS infrastructure.
Oblivious DNS
Techniques to hide DNS metadata like which domains are being queried. Prevents surveillance and censorship.
Centralized DNS
Enterprise or provider controlled DNS can offer greater consistency and security than the open internet DNS infrastructure.
Response Policy Zones
Allow defining custom DNS rules and policies for blocks of client IPs. Can limit exposure to malicious domains.
The Future of DNSSEC
DNSSEC solves major security weaknesses in DNS and offers a robust trust framework. But challenges around adoption, complexity, and overheads remain. However, the long-term importance of securing the DNS infrastructure will continue to drive deployment, improvement, and possibly evolution of DNSSEC technologies.
Conclusion
DNSSEC adds digital signature capabilities to DNS, securing it against spoofing and manipulation through public-key cryptography. This establishes a chain of trust originating from the root zone. Despite adoption challenges, DNSSEC’s security benefits make it an essential technology for hardening the backbone of the internet. Implementation requires some effort but brings protections that are crucial as DNS becomes an increasingly high-value target for attackers.