DNS Records & Concepts
What is DNSSEC?
DNSSEC, DNS Security Extensions, is a suite of specifications that adds cryptographic authentication to the DNS system. It allows DNS resolvers to verify that the DNS records they receive are authentic, that they came from the legitimate authoritative nameserver for a domain and have not been modified in transit or forged by an attacker.
Without DNSSEC the DNS system has no built-in mechanism for verifying the authenticity of responses. A recursive resolver that receives an answer to a DNS query cannot confirm whether the answer came from the legitimate authoritative nameserver or from an attacker who intercepted the query and injected a fraudulent response. This vulnerability enables DNS hijacking attacks like cache poisoning, where attackers inject false records into resolver caches, causing resolvers to direct users to malicious servers.
DNSSEC addresses this by adding digital signatures to DNS records. The authoritative nameserver signs records with a private cryptographic key. Resolvers that support DNSSEC validation verify the signatures using the corresponding public key before accepting and caching the records. A forged record, one without a valid signature from the legitimate authoritative nameserver, is rejected. A modified record, one where the signature no longer matches the content, is rejected. Only cryptographically verified authentic records are accepted and served to clients.
DNSSEC does not encrypt DNS records, the content of DNS queries and responses remains visible to network observers. It provides authentication, proof that records are genuine, not confidentiality. Encryption of DNS traffic is provided by separate mechanisms like DNS over HTTPS and DNS over TLS.
How DNSSEC works
DNSSEC operates through a chain of cryptographic trust that extends from the DNS root zone downward through TLDs to individual domain zones. Each level of the hierarchy signs its own records and publishes information that allows the next level down to be verified, creating a continuous chain of trust from the globally trusted root.
Cryptographic key pairs: DNSSEC uses public-key cryptography. Each signed zone has at least one key pair, a private key used to create signatures and a corresponding public key used to verify them. The private key is kept secret on the authoritative nameserver infrastructure. The public key is published in the zone as a DNSKEY record.
Two key types are typically used in DNSSEC deployments.
The Zone Signing Key, ZSK, is used to sign the actual DNS records in the zone. It is rotated frequently, every few months, to limit exposure if the key is compromised.
The Key Signing Key, KSK, is used to sign the ZSK and other DNSKEY records. It is rotated less frequently, annually or less, because establishing trust for a new KSK requires coordination with the parent zone.
Zone signing: when DNSSEC is enabled for a zone the authoritative nameserver signs each DNS record set, a set of all records of the same type for the same name, with the ZSK private key. The signature is stored in an RRSIG record alongside the signed records. Every record in the zone, A records, CNAME records, MX records, and all others, has a corresponding RRSIG record.
DS records, delegation signer: the KSK public key is hashed to create a DS record, delegation signer. The DS record is published in the parent zone, for example.com the DS record goes in the .com TLD zone. The DS record links the child zone’s DNSSEC configuration to the parent zone’s chain of trust. The parent zone signs the DS record with its own keys creating a verifiable link between the two zones.
Chain of trust: the chain of trust extends from the root zone, which is signed and whose public key is known to all DNSSEC-validating resolvers as the trust anchor, through each level of the hierarchy. The root zone’s DS records vouch for TLD zones. TLD zone DS records vouch for registered domain zones. Each link is cryptographically verifiable.
Validation by resolvers: when a DNSSEC-validating resolver queries for a record it receives the record and its RRSIG signature. It retrieves the DNSKEY record containing the public key. It verifies the signature matches the record content and was created by the private key corresponding to the public key. It then verifies the DNSKEY record itself by checking the DS record in the parent zone. It verifies the parent zone’s DS record by checking the grandparent zone, and so on up to the root. If every link in the chain verifies correctly the record is accepted as authentic.
If any link fails, the signature does not match the record content, the public key does not correspond to the private key that created the signature, the DS record in the parent zone does not match the child zone’s KSK, the resolver returns SERVFAIL to the client rather than the unverified record. The domain becomes inaccessible to DNSSEC-validating resolvers until the configuration is fixed.
DNSSEC record types
DNSSEC adds several new record types to the DNS system that carry cryptographic information.
DNSKEY: contains the public key used to verify DNSSEC signatures in a zone. Each zone has at least one DNSKEY record, the KSK, and typically a second, the ZSK. The DNSKEY record is signed by the KSK creating a self-referential signature for the key set. Resolvers retrieve DNSKEY records to obtain the public keys needed for signature verification.
RRSIG: Resource Record Signature. Contains the cryptographic signature for a set of DNS records. Every signed record set has a corresponding RRSIG record specifying the signature algorithm, the key that created the signature, the validity period, and the signature value itself. Resolvers verify RRSIG records to authenticate DNS responses.
DS: Delegation Signer. Published in the parent zone to establish trust in a child zone’s DNSSEC configuration. Contains a hash of the child zone’s KSK public key. When a resolver retrieves the child zone’s DNSKEY records it verifies the hash against the DS record in the parent zone, confirming the child zone’s keys are legitimate.
NSEC and NSEC3: Next Secure records. Used to authenticate negative responses, proving that a queried name does not exist in the zone. Without NSEC/NSEC3 an attacker could forge NXDOMAIN responses claiming a domain does not exist when it does. NSEC records list the next existing name in the zone, allowing resolvers to verify no names exist between two adjacent names. NSEC3 uses hashed names rather than plaintext names, preventing zone enumeration by hiding the actual record names while still proving non-existence.
CDS and CDNSKEY: child DS and child DNSKEY records. Published in a child zone to signal desired changes to the DS record in the parent zone. Used to automate key rollovers and initial DNSSEC setup, the parent zone operator can detect CDS/CDNSKEY records and automatically update the DS records without manual intervention.
The DNSSEC chain of trust
The chain of trust is the most fundamental concept in DNSSEC, the unbroken cryptographic linkage from the globally trusted root zone to individual domain zones that allows resolvers to verify any signed domain.
The root zone trust anchor: the starting point of trust in DNSSEC. The root zone, the top of the DNS hierarchy, is signed. The public key for the root zone’s KSK is the trust anchor, a value known to all DNSSEC-validating resolvers and embedded in their software. ICANN manages the root zone keys and performs periodic key rollovers with advance notice to resolver operators.
TLD signing: most major TLDs, .com, .net, .org, and hundreds of others, are signed with DNSSEC. Their DNSSEC public keys are published as DS records in the root zone, establishing the chain from the root to each TLD.
Domain signing: domain owners enable DNSSEC on their zone and submit the DS record, a hash of their KSK, to their domain registrar. The registrar publishes the DS record in the TLD zone, establishing the chain from the TLD to the domain.
Complete chain: a resolver validating example.com follows the chain: root zone public key (trusted anchor) → root zone signs .com DS records → .com DS records vouch for example.com KSK → example.com KSK signs ZSK → ZSK signs all zone records. Each link is cryptographically verifiable. The chain is complete and unbroken.
Broken chain: if any link in the chain is missing or incorrect DNSSEC validation fails. A domain that has DS records in the TLD zone but misconfigured DNSSEC on its authoritative nameservers causes SERVFAIL for all users of validating resolvers. This is one of the most significant operational risks of DNSSEC, misconfiguration breaks the domain for a significant portion of internet users.
DNSSEC and redirect management
DNSSEC interacts with redirect management in specific ways that domain owners connecting domains to redirect infrastructure should understand.
DNSSEC does not affect redirect rules: DNSSEC operates at the DNS authentication layer and has no direct interaction with HTTP redirect rules. A domain with DNSSEC enabled functions identically from a redirect perspective to one without DNSSEC. DNSSEC simply adds cryptographic verification to the DNS records that connect the domain to redirect infrastructure, it does not change how those records work.
DNSSEC must be compatible with redirect infrastructure DNS changes: when connecting a domain to redirect infrastructure by updating A records or CNAME records the zone signing process must handle the new records correctly. If the zone is signed and new records are added without re-signing the zone or if the signing process is automated the new records get signed automatically. Manual DNSSEC management requires re-signing the zone whenever records are added or changed.
DNSSEC and nameserver changes: if changing nameservers as part of a redirect management setup, moving DNS to a provider like Cloudflare that handles redirect configuration, the DNSSEC chain of trust must be maintained through the transition. The new provider must support DNSSEC. The DS records in the TLD zone must be updated to reflect the new provider’s KSK. The transition must be sequenced correctly to avoid breaking the chain of trust during the nameserver change.
DS record submission via registrar: enabling DNSSEC for a domain requires submitting DS records to the domain registrar who publishes them in the TLD zone. Most managed DNS providers that support DNSSEC provide the DS record values to submit. The registrar’s control panel accepts DS record submissions, either manually or through automated protocols like CDS/CDNSKEY processing.
DNSSEC implementation
Implementing DNSSEC involves steps at both the DNS provider level and the domain registrar level, both sides must be correctly configured for DNSSEC to work.
Enabling DNSSEC at the DNS provider: managed DNS providers that support DNSSEC handle zone signing automatically when DNSSEC is enabled for a zone. Cloudflare Route 53 Google Cloud DNS and most major providers generate keys sign the zone and maintain signatures automatically. The provider generates the DS record value that must be submitted to the registrar.
For self-hosted authoritative nameservers zone signing requires configuring DNSSEC in the nameserver software, BIND PowerDNS Knot DNS, specifying key algorithms and managing key generation. The zone signing process must be maintained continuously, re-signing records as they change and managing key rollovers.
Submitting DS records to the registrar: after enabling DNSSEC at the DNS provider the DS record must be published in the parent zone, the TLD zone. This is done by submitting the DS record to the domain registrar through their control panel or API. The registrar forwards the DS record to the TLD registry which publishes it in the TLD zone.
Without the DS record in the TLD zone DNSSEC validation for the domain is not triggered, resolvers validate from the chain of trust downward and without a DS record in the parent zone they have no starting point for validating the child zone. The domain continues to work but DNSSEC protection is not active.
Key rollover: cryptographic keys must be rotated periodically, both for security best practice and because key validity periods expire. ZSK rollovers occur frequently. KSK rollovers are less frequent but require updating the DS record in the parent zone when the KSK changes.
Managed DNS providers that support DNSSEC handle ZSK rollovers automatically. KSK rollovers require coordination, the new KSK must be introduced alongside the old one allowing resolvers to cache both before the old one is removed and the DS record in the parent zone is updated. The rollover sequence must maintain a valid chain of trust throughout.
Incorrect key rollovers, removing the old key before resolvers have cached the new one or updating the DS record before the new key is published in the zone, break the chain of trust and cause SERVFAIL for all validating resolvers. This is the most common operational failure mode in DNSSEC deployments.
DNSSEC validation adoption
DNSSEC validation is performed by resolvers that have been configured to validate signatures. Not all resolvers validate DNSSEC, the adoption of validation has been gradual.
Major public resolvers, Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9: all perform DNSSEC validation. ISP resolver validation varies by provider and region. Enterprise resolvers increasingly validate DNSSEC as security awareness grows.
Estimates suggest that 30 to 40 percent of DNS queries worldwide are validated by DNSSEC-aware resolvers. This proportion is growing as resolver operators enable validation and as DNSSEC awareness increases.
The consequence of validation adoption is that DNSSEC misconfiguration affects a significant and growing portion of internet users. A domain with broken DNSSEC, invalid signatures, missing DS records, failed key rollovers, returns SERVFAIL to all validating resolvers. Users of those resolvers cannot access the domain at all.
Checking DNSSEC status
Several tools check whether DNSSEC is correctly configured for a domain.
dig with DNSSEC flags: requesting DNSSEC records explicitly:
Returns the A record alongside its RRSIG signature record. The presence of an RRSIG record indicates the zone is signed.
Checking for DS record in parent zone:
Returns the DS record from the TLD zone, confirming the chain of trust is established. No DS record indicates DNSSEC is not active even if the zone is signed.
Online DNSSEC validators: tools like Verisign’s DNSSEC Analyzer, DNSViz, and ICANN’s DNSSEC Debugger provide visual analysis of DNSSEC configurations, showing the chain of trust, identifying broken links, and flagging configuration issues. DNSViz in particular provides detailed graphical output showing each element of the DNSSEC chain and highlighting any validation failures.