Industries that collect user data, such as finance, healthcare, and government, are high-profile targets for DNS attacks because the data is compelling for malicious actors. Incorporating a variety of security mitigations, including Domain Name System Security Extensions to prevent spoofing attacks, can help an organization prevent data breaches and protect its users and their data from misuse.
This article describes how DNS Security Extensions (DNSSEC) creates additional security for your domain, clarifies the regulatory need for DNSSEC implementation, and evaluates risks associated with using DNSSEC.
What is DNSSEC?
DNS, or the Domain Name System, provides the routing infrastructure to connect a website visitor to the appropriate IP address that corresponds with a domain name. The DNS Security Extensions, also known as DNSSEC, offers authenticity resolution for DNS records, verifying the resource record signature ([.rt-script]RRSIG[.rt-script]) with a public key stored in the record ([.rt-script]DNSKEY[.rt-script]). In a sense, DNSSEC retrieves a signature for the DNS record, confirming that a website is authentic through public key cryptography. DNSSEC extends the DNS protocol with cryptographic authentication.
With DNSSEC enabled for your domain, a DNS resolver will check the DNS data for a chain of trust associated with your domain's authentication setup. The resolver will verify that the digital signatures originate from a trusted zone that can be cryptographically confirmed, which is referred to as data origin authentication. Additionally, DNSSEC provides data integrity protection against DNS cache poisoning attacks to affirm that data in transit has not been modified so that the DNS resolver can return the verified site to the client browser. If authentication and validation fail, then the resolver will return an error instead of the website.
Without these security provisions, a resolver could redirect a user to an attacker's chosen site through DNS spoofing or DNS cache poisoning. How DNSSEC works with data origin authentication and integrity is detailed in the Internet Engineering Task Force (IETF)'s Request for Comments 4033 (RFC 4033.
DNSSEC uses a chain of trust to assert top-down authenticity from the root zone. Top-level domain (TLD) operators create a trust anchor to the DNS root zone. The Internet Assigned Numbers Authority (IANA) coordinates DNS resources, including root zone management and Key Signing Key operations for TLD trust anchor connections. When TLDs provide a trust anchor to the DNS root zone, any domain owners who register with that TLD can set up DNSSEC with a chain of trust that resolves back to the signed and verified root zone. Further information about zone signing and resolving can be found in the IETF's RFC 4035. If the signed zone is required (as is the case when deploying DNSSEC), then access to the domain is more limited since it must be authenticated but it is likewise protected against adversary-in-the-middle attacks.
Though DNSSEC adds a beneficial authentication feature for domains, it is not yet widely deployed. APNIC Labs reports that worldwide DNSSEC validation rates total 40% with 8.35% of those being partial validation only.
DNSSEC and United States regulatory requirements
While DNS Security Extensions is not mandated by many compliance regulations, it is a necessary configuration for United States federal regulatory needs. Between the Federal Information Security Management Act (FISMA) and NIST's published standards (including Special Publication 800-53 and Federal Information Processing Standard 140-2), United States federal agencies and third-party providers for those federal agencies have a variety of security baselines to achieve. NIST SP 800-81-2 provides a Secure DNS Deployment Guide that includes sections for using DNS Security Extensions.
NIST SP 800-53 includes a set of controls related to System and Communication Protection, referred to as "SC." SC-21 and SC-22 set out the expectations for DNS resolution, including a validation through DNSSEC or another authenticated channel in SC-21. There does not appear to be meaningful change for this control from Revision 4 to the newly implemented Revision 5 (Rev 5).
The Federal Risk and Authorization Management Program (FedRAMP) certification includes DNSSEC in the required control scope, and organizations moving through the certification process must attest to their DNSSEC configuration or accept the risk threshold of not implementing DNSSEC. The FedRAMP Readiness Assessment Report includes the following questions in relation to your organization's DNSSEC configuration:
- "Does the system’s external DNS solution support DNS Security (DNSSEC) to provide origin authentication and integrity verification assurances? This applies to the controls SC-20, SC-21, and SC-22 in the SSP." (section 4.1)
- "Did the 3PAO [third-party assessment organization] verify that the external DNS server replies with valid DNSSEC responses and that the recursive server is within a FedRAMP Authorized boundary, makes DNSSEC requests for domains outside the boundary, and that DNS calls maintain DNSSEC authentication and integrity? [SC-20, SC-21]" (section 4.2)
The National Institute of Standards and Technology (NIST) estimates fewer than 1100 US government IPv6 domains with an operational DNSSEC deployment, 73 operational industry deployments, and 30 operational university deployments with the majority of university DNSSEC deployments unsigned (as of January 8, 2023).
The limited implementation of DNSSEC worldwide may be, in part, because it has not been mandated by all compliance certifications. It may also be that domain owners and administrators have accepted the level of risk associated with not using DNSSEC as they may have alternative security measures to protect against the risks.
DNSSEC and cybersecurity risks
DNSSEC offers protection against a variety of DNS attacks, including the following:
- DNS spoofing and DNS cache poisoning, where the DNS resolver returns false information, such as an attacker's malicious website.
- DNS hijacking, where an attacker redirects the query.
- Adversary-in-the-middle attacks (sometimes referred to as man-in-the-middle attacks or person-in-the-middle attacks), where an attacker intercepts communication and potentially modifies information in transit. Adversary-in-the-middle attacks are limited due to DNSSEC validation as the attacker cannot sign their interception with the necessary key.
The authentication and validation provided by DNS Security Extensions adds protection against certain attack types but it is not the end-all cyber attack prevention strategy. For example, public key infrastructure (PKI) on the web, such as SSL/TLS certificates, helps to protect websites and improve user confidence in the website they visit, so web PKI sometimes displaces the perceived need for DNSSEC. However, DNSSEC protects the domain owner from an attacker's spoofing attack. Pairing DNSSEC with web PKI provides complementary security tactics for both administrator and user peace of mind.
DNSSEC also provides security that can help protect against DNS tunneling, but it does not directly prevent payload attachments to DNS queries. Likewise, DNSSEC does not protect against denial-of-service attacks or typosquatting, so it is important to implement a variety of security techniques that account for the breadth of attack types.
Because DNSSEC generates a signed zone for your domain, it can expose any subdomains within the signed zone. While some zone data is benign (most websites are expected to have a [.rt-script]www[.rt-script] subdomain, for example), any private login pages or internal access subdomains could be inspected and perhaps attacked by a curious hacker. The verification of DNS response data can be accomplished across both parent zones and child zones for your domain.
How to configure DNSSEC
DNSSEC configuration occurs at the domain provider level. The domain owner and all service providers are involved in the DNSSEC process: domain owner, domain registrar, domain registry, and DNS provider. Both the registrar and registry must support DNSSEC.
The DNSSEC configuration process includes three tasks:
- Set up DNSSEC with your DNS hosting provider and create the necessary records.
- Activate the records with your domain registrar (in some cases, the hosting provider and the domain registrar may be the same organization, such as Cloudflare).
- Enable signature validation across DNS servers.
Your resource records for DNSSEC implementation include [.rt-script]A[.rt-script] or [.rt-script]AAAA[.rt-script] records for your IP address, the [.rt-script]DNSKEY[.rt-script] record, the [.rt-script]DS[.rt-script] record for delegation signer, and the [.rt-script]RRSIG[.rt-script] record. To create a [.rt-script]DS[.rt-script] record with your domain registrar, you will also need the key signatures for your DNS zone, typically a Key Signing Key (KSK) and a Zone Signing Key (ZSK), as well as the key tag, algorithm, digest type, and digest.
Domain registrars and hosting providers often provide support documentation for DNSSEC. You can search directly in the provider's documentation or use these links for popular providers:
- Amazon Web Services (AWS): Configuring DNSSEC signing in Amazon Route 53
- Cloudflare: Enable DNSSEC
- dnsimple: DNSSEC guide
- GoDaddy: Turn DNSSEC on or off
- Google Domains: Set up DNSSEC & DNS security
- Squarespace: Nameservers and DNSSEC for Squarespace-managed domains
However, Microsoft Azure does not currently support DNSSEC.
Continuous monitoring can help you keep track of your security implementations, including the current status of your DNSSEC configuration.
How UpGuard can help
Alongside other configuration risks and software vulnerabilities, UpGuard BreachSight scans your external attack surface to assess your DNS configuration settings. For DNS-related findings, BreachSight provides two notifications:
- DNSSEC not enabled
- 'DNS' port open
The DNSSEC not enabled finding reports that your domain deployment has not been configured with DNSSEC. Set up DNSSEC in order to authenticate responses to DNS requests and confirm that only authorized resolutions will be returned to users. By including DNSSEC in your domain configuration, you can prevent attackers from inserting their own domain during a DNS resolution.
If you receive the 'DNS' port open finding, then your server has not protected the DNS port against public threats like DNS cache poisoning, adversary-in-the-middle attacks, or DNS spoofing. DNS uses port [.rt-script]53[.rt-script] for both UDP and TCP connection. Your risk finding in UpGuard will identify which port DNS listens on if it is exposed to the public internet. To prevent DNS exploitation, close the port to the public internet. If you need to maintain some access between the public internet and your DNS service, consider limiting access to hardened servers that are regularly maintained and implementing DNSSEC for zone protection. Keep in mind that DNSSEC can expose your subdomain architecture.
Current UpGuard users can log in and access their Risk Profile in BreachSight to assess whether these DNS-related findings impact their organization. For more information about other services UpGuard identifies through port scanning, see our support article on What services does UpGuard identify with port scanning.
