[Blog](/blog) Show links Resources [Blog](/blog) [Breaches](/breaches) [eBooks, reports, & more](/resources) [Events](/events) [News](/news) [Risks and Vulnerabilities](/category/risks-and-vulnerabilities) Show links Categories [Attack Surface Management](/category/attack-surface-management) [Company News](/category/company-news) [Compliance and Regulations](/category/compliance-and-regulations) [Cybersecurity](/category/cybersecurity) [Data Breaches](/category/data-breaches) [DevOps](/category/devops) [Human Cyber Risk](/category/human-cyber-risk) [Risks and Vulnerabilities](/category/risks-and-vulnerabilities) [Third-Party Risk Management](/category/third-party-risk-management) [Vendor Risk Management](/category/vendor-risk-management) [DNS Security Extensions (DNSSEC) and Cybersecurity Risk](/blog/dnssec-risk) Publish date October 26, 2026 {x} minute read # DNS Security Extensions (DNSSEC) and Cybersecurity Risk [Get a demo](/contact-sales) [Free trial](/demo) [Download the PDF guide](/resources/the-website-security-checklist) [Free trial](/demo) Written by [Caitlin Postal](/team/caitlin-postal) Technical Writer Reviewed by Table of contents Checklist The Website Security Checklist Free resource ### The Website Security Checklist [Download now](/resources/the-website-security-checklist) Industries that collect user data, such as [finance](https://www.upguard.com/industries/financial-services), [healthcare](https://www.upguard.com/industries/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](https://www.upguard.com/blog/data-breach) 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](https://www.upguard.com/blog/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 that corrupt a [DNS cache](https://www.upguard.com/blog/cache) 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](https://www.upguard.com/blog/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](https://datatracker.ietf.org/doc/html/rfc4033). 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](https://datatracker.ietf.org/doc/html/rfc4035). 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](https://www.upguard.com/blog/man-in-the-middle-attack). Though DNSSEC adds a beneficial authentication feature for domains, it is not yet widely deployed. [APNIC Labs](https://stats.labs.apnic.net/dnssec) 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](https://www.upguard.com/blog/fisma)) and NIST's published standards (including [Special Publication 800-53](https://www.upguard.com/blog/nist-sp-800-53) and [Federal Information Processing Standard 140-2](https://www.upguard.com/blog/fips-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](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf) 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](https://csf.tools/reference/nist-sp-800-53/r4/sc/sc-21/) and [SC-22](https://csf.tools/reference/nist-sp-800-53/r5/sc/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](https://www.upguard.com/blog/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](https://usgv6-deploymon.antd.nist.gov/snap-all.html), 73 operational industry deployments, and 30 operational university deployments with the majority of [university DNSSEC deployments unsigned](https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-edu) (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](https://www.upguard.com/blog/cache-poisoning), where the DNS resolver returns false information, such as an attacker's malicious website. * DNS [hijacking](https://www.upguard.com/blog/domain-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](https://www.upguard.com/blog/ssl-certificate), 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](https://www.upguard.com/blog/what-is-a-ddos-attack) attacks or [typosquatting](https://www.upguard.com/blog/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](https://www.upguard.com/blog/domain-name-registrar), domain registry, and DNS provider. Both the registrar and registry must support DNSSEC. The DNSSEC configuration process includes three tasks: 1. Set up DNSSEC with your DNS hosting provider and create the necessary records. 2. 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). 3. 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](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html) * Cloudflare: [Enable DNSSEC](https://developers.cloudflare.com/dns/dnssec/#enable-dnssec) * dnsimple: [DNSSEC guide](https://support.dnsimple.com/articles/dnssec/) * GoDaddy: [Turn DNSSEC on or off](https://www.godaddy.com/help/turn-dnssec-on-or-off-6420) * Google Domains: [Set up DNSSEC & DNS security](https://support.google.com/domains/answer/6147083) * Squarespace: [Nameservers and DNSSEC for Squarespace-managed domains](https://support.squarespace.com/hc/en-us/articles/4404183898125-Nameservers-and-DNSSEC-for-Squarespace-managed-domains) However, [Microsoft Azure does not currently support DNSSEC](https://learn.microsoft.com/en-us/azure/dns/dns-faq#does-azure-dns-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](https://www.upguard.com/category/risks-and-vulnerabilities), [UpGuard Breach Risk](https://www.upguard.com/product/breach-risk) scans your external attack surface to assess your DNS configuration settings. For DNS-related findings, Breach Risk 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 Breach Risk](https://cyber-risk.upguard.com/risk_profile) 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](https://help.upguard.com/en/articles/4530963-what-services-does-upguard-identify-with-port-scanning). Checklist The Website Security Checklist Free resource ### The Website Security Checklist [Download now](/resources/the-website-security-checklist) ## Related posts Learn more about the latest issues in cybersecurity. Risks and Vulnerabilities #### [25 Security Vulnerabilities That Have Defined the 2020s (Thus Far)](/blog/top-25-security-vulnerabilities-of-the-2020s) From Log4j to SolarWinds, discover the 25 critical security vulnerabilities that have reshaped cybersecurity thus far in the 2020s. [](/team/nicholas-sollitto) [Nicholas Sollitto](#) May 28, 2026 Risks and Vulnerabilities #### [ServiceNow Vulnerabilities: CVE-2024-4789 and CVE-2024-5217](/blog/servicenow-vulnerabilities) Learn about two critical vulnerabilities affecting the ServiceNow platform (CVE-2024-4789 and CVE-2024-5217) and how UpGuard can help. [](/team/nicholas-sollitto) [Nicholas Sollitto](#) January 16, 2025 Risks and Vulnerabilities #### [PHP2Shell: A Clear Explanation and Response Framework](/blog/php2shell-a-clear-explanation-and-response-framework) PHP2Shell (CVE-2026-109618 and CVE-2026-109619) lets unauthenticated attackers run code on PHP servers. Learn who’s affected and how to respond. [](/team/upguard) [UpGuard Team](#) October 26, 2026 Risks and Vulnerabilities #### [Everything Everywhere: Systemic Data Exposure in Supabase Apps](/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps) Supabase is a favorite of AI coding agents. It's also prone to misconfiguration. We studied more than 16,000 open databases to see what's leaking. [](/team/greg-pollock) [Greg Pollock](#) October 14, 2026 Risks and Vulnerabilities #### [Oracle Just Shipped 1,449 Security Patches in One Quarter. We Checked How Much of It Is Actually New.](/blog/oracle-just-shipped-1-449-security-patches-in-one-quarter-we-checked-how-much-of-it-is-actually-new) Oracle's July 2026 update shipped 1,449 security patches — 2.8x its all-time record. We parsed 23 quarters of advisories to find out how much is truly new. [](/team/greg-pollock) [Greg Pollock](#) July 22, 2026 Risks and Vulnerabilities #### [Data leakage risks with DBHub MCP servers](/blog/data-leakage-risks-with-dbhub-mcp-servers) UpGuard found exposed DBHub servers leaking live databases to the open internet—an early sign that MCP exposure is becoming a systemic data risk. [](/team/greg-pollock) [Greg Pollock](#) October 13, 2026 [All posts](/blog) Experience superior visibility and a simpler approach to cyber risk management [Get a demo](/contact-sales) [Free trial](/demo)