Summary
DNSSEC (Domain Name System Security Extensions) protects against man-in-the-middle attacks and DNS hijacking by validating DNS responses with digital signatures. It is very effective, but many organizations have not adopted it because it is hard to set up and manage across the life of a domain and a large domain portfolio. This discussion paper from Authentic Web explains what DNSSEC is, how it works, why adoption is low and how a unified, automated DNS management approach makes it practical.
The Domain Name System (DNS) underpins every digital service. Yet, domain and DNS audits reveal major compliance gaps in security policy enforcement. Manual change management processes do not work in the digitally transformed enterprise.
Peter LaMantia, CEO, Authentic Web Inc.
Key points
- Without DNSSEC, organizations are exposed to DNS hijacking and spoofing, mostly through DNS cache poisoning.
- Adoption is held back by cost and complexity: multiple registrars and DNS providers, a chain of trust across registrars, DNS providers and TLD registries, manual key management, and annual DS key rollovers.
- The most important test that DNSSEC works is checking that the RRSIG and DS records are present and valid. A broken link in the chain of trust can invalidate authentication without anyone noticing.
- Four steps prepare an organization for DNSSEC: audit the DNS network, standardize security policies, consolidate DNS providers and unify change management.
The need for comprehensive DNS security
Internet users rely on organizations to keep online services available and protect their data, and they need to trust that a brand’s web presence is authentic. That trust is threatened by weaknesses in the internet’s foundation, the Domain Name System. Every online action starts with DNS, which directs requests to the destinations, content and applications users want. That criticality makes DNS a target for hijacking, spoofing, man-in-the-middle attacks and other threats that can hurt brand reputation and user security.
Infrastructure leaders should cover several best-practice defenses in their DNS security policy: DNSSEC, SPF (Sender Policy Framework), DMARC (Domain-based Message Authentication, Reporting and Conformance), a secondary DNS network and an HTTPS Everywhere policy, all enforced with change management controls. This paper looks in depth at DNSSEC. Traditional manual practices and the common use of multiple DNS services make DNSSEC deployment cumbersome, inefficient and costly. Consolidating all domains and DNS services into a unified, automated environment simplifies and secures operations.
What is DNSSEC?
DNSSEC is a security protocol that validates DNS query responses. It protects internet users from forged DNS data in recursive servers, often called DNS cache poisoning. It uses tamper-proof, digitally signed keys to verify the authenticity of a domain’s zone files and sends users to the brand’s genuine destination.
DNS was developed in the 1980s to make the internet easier to use. It works like a directory, translating the words typed into a browser into the IP address where content is served (for example, apple.com to 17.253.134.10 at the time of writing). DNS was not designed to be very secure, and for years malicious parties have intercepted, forged or manipulated query responses, so users cannot always be sure content is from a legitimate source. DNSSEC was the industry response, developed by the Internet Engineering Task Force (IETF) to counter this impersonation problem.
How does DNSSEC work?
DNS is organized into zones and uses resolvers to direct queries. DNSSEC matches two digital keys, one public and one private, and the keys themselves are signed as part of a chain of trust. The private key is known only to the domain owner and is used to sign the DNS data. The recursive DNS server compares the signature to the public key in the TLD registry records. If they match, the user receives the records and reaches the authentic website. If they differ, the records are treated as a forgery and discarded without being returned to the user.
This protects users from being misdirected to fraudulent destinations. A shopper at a luxury retailer’s site, or a banking customer, expects to be at the real site and not an imposter built to intercept and steal information.
What can happen without DNSSEC?
Without DNSSEC, organizations are exposed to DNS hijacking or spoofing, largely through DNS cache poisoning. Recursive servers store query data for efficiency, and that cached data can be modified to return a falsified response. A user sent to a fraudulent site is open to malware and viruses, and attackers can even present the fake site with a valid SSL certificate to trick users into logging in. DNS hijacking has led to stolen data and credentials. DNS attacks can disable websites, interrupt sales and cost loyal customers, and can bring lawsuits and regulatory penalties.
Every sector is vulnerable, but attackers go where the money is. Organizations that store payment data, such as finance, banking, healthcare and online payment services, are at high risk, and government and membership services such as hotel loyalty programs are frequently targeted.
Why DNSSEC is only now being adopted
DNSSEC is a proven defense against DNS hijacking, but many organizations have not deployed it. The paper gives two reasons, both about perceived complexity and cost.
- How companies manage external DNS. Most large organizations use multiple registrars and often many more managed DNS services because of legacy decisions or acquisitions. Not all DNS providers support DNSSEC and they rarely integrate with registrar systems, so deployment can be inconsistent or unfeasible for large parts of the portfolio.
- A coordinated chain of trust. Domain registrars, DNS providers and TLD registries each contribute to the chain for every query. With so many parties, consistent low-effort administration across a portfolio is difficult.
Internally, organizations often lack the expertise to implement and maintain DNSSEC. Setting up DS keys and RRSIGs at the DNS service and keeping them in sync with registrars and registries is typically manual. DS keys also roll over each year, adding complexity over every domain’s life. Verifying correct operation means constantly checking that signing keys are present and valid, which is formidable for hundreds or thousands of domains. A lookup tool may report that keys are present even when the DS key has expired or the RRSIG has changed, so all keys must be tracked and rolled across multiple systems.
Despite the complexity, research from Verisign Labs shows DNSSEC use growing quickly in recent years, because the rate of compromised customers is rising and because new automation tools help teams manage DNSSEC over the domain lifecycle.
How to ensure your DNSSEC is working
With so many moving parts, a broken link in the chain of trust can invalidate authentication while everyone assumes DNSSEC is active. The key test is the presence and validity of the resource record signature (RRSIG) and the delegation signer (DS) key. The two failure modes behave differently:
| Problem | Result |
|---|---|
| Invalid RRSIG | DNS will not return a query result. DNS security stays intact, but users are blocked from the content. |
| Missing or expired DS key at the TLD registry | DNS keeps returning results, but they are not authenticated and are open to exploitation and misuse. |
Testing DNSSEC validity across all domains is tedious and manual, possibly across several registries. Tools such as Verisign Labs’ DNSSEC Analyzer exist, but most test one domain at a time, which is impractical for large portfolios and does not monitor in real time. The most effective approach is an integrated, end-to-end domain and DNS change management system. Otherwise DNSSEC can be misconfigured or running with expired keys that give no protection.
How to implement DNSSEC
The biggest problem is not the protocol but inefficient DNS management caused by manual, legacy processes. Four steps prepare an organization for DNSSEC:
- Audit your DNS network. Run an apex-level DNS audit. Identify all domain registrars and managed DNS providers touching your digital assets. Test pass/fail for DNSSEC on every domain, and validate DMARC, SPF and TLS/SSL certificates on all domains and redirect domains.
- Standardize security policies. Every domain and its zone file needs common compliance policies, including DNSSEC rules, applied consistently across hundreds or thousands of domains. Inconsistent use of SOA, SPF, DMARC and DNSSEC are gaps that attackers target.
- Consolidate your managed DNS service providers. DNSSEC is prohibitively complicated across multiple providers and platforms. If a test finds an invalid key, the administrator must pick the right DNS admin portal, fix it and copy keys into a registrar system. Multiplied across a large portfolio, that will not get done. The solution is a single registrar and DNS provider with integrated DNSSEC support.
- Adopt unified control systems for change management. Use one change management system that integrates domain registration and DNS management in a single secure interface, with DNSSEC and other DNS security measures inside its change controls. That gives a single source of truth and a central management hub.
A systems-based approach to DNSSEC
DNSSEC should be as easy as opening a domain record in a secure admin portal and switching it on. The system creates the DS keys and RRSIGs on the DNS and copies them to the TLD registry. A year later, a DNSSEC monitor confirms everything is still compliant. An automated domain and DNS change management system should also:
- Manage and monitor signing key expiry dates and rollovers.
- Monitor DNSSEC settings with scheduled scans and report problems for remediation.
- Log all administrative and system changes in a tamper-proof audit record.
- Report all changes through alerts and digests to an authorized hierarchy.
Only a systems-based approach removes the manual, error-prone processes that have made DNSSEC so hard to implement. To find the security and management gaps in your own organization, contact Authentic Web at info@authenticweb.com or 1.855.436.8853.