Authentication of DNS keys and data is ultimately a matter of local policy, which may extend or override the DNSSEC protocol extensions. A validating resolver must always be guided by local policy when deciding whether to authenticate a new public key.

dns, security

DNSSEC deliberately does not provide confidentiality, as DNS was designed on the assumption that responses are identical regardless of the querier and all data is visible. Access control lists and differentiation between inquirers are explicitly out of scope.

dns, security, privacy

DNSSEC provides object security (data origin authentication for DNS RRsets) rather than channel security (transaction authentication). This means DNSSEC keys are associated with the zone itself, not with its authoritative name servers. Transaction authentication (TSIG, SIG(0)) is a separate mechanism.

dns, security, crypto

The DS RR at a delegation point contains a hash of the child zone's DNSKEY, simplifying cross-organizational signing by allowing the parent zone administrator to vouch for the child zone's key without needing to sign the child's data directly.

dns, security, crypto

The KSK/ZSK operational split allows the KSK to remain offline even for zones with dynamic update enabled (where the ZSK must be kept online for re-signing). This limits the exposure of the more stable, longer-lived key signing key.

dns, security, crypto

Any security-oblivious DNS software between a security-aware resolver and the authoritative name servers—including NAT proxies with built-in DNS proxies—will interfere with DNSSEC, potentially preventing the resolver from obtaining or validating signed data or DS RRs.

dns, security, nat

DNSSEC alone does not protect zone transfer operations, since signed zones still contain unsigned non-authoritative data (glue and NS RRs). Zone transfers must be secured by additional channel-security mechanisms such as TSIG, SIG(0), or IPsec.

dns, security

The current DNSSEC signaling mechanism does not distinguish between the Indeterminate and Insecure states, and no format is defined for communicating why a response was found to be bogus; these are identified as topics for future work.

dns, security

TTL values and RRSIG validity periods are distinct: TTL controls cache coherency and cannot extend signature validity, but a resolver may use the RRSIG expiration time as an upper bound on the TTL it assigns to a cached signed RRset.

dns, security

A security-aware name server should include appropriate DNSSEC records (RRSIG, DNSKEY, DS, NSEC) in all responses to resolvers that have signaled willingness via the DO bit in the EDNS header, subject to message size limitations.

dns, security

A security-aware resolver should be configured with at least one trust anchor as the starting point from which it attempts to establish authentication chains.

dns, security

A security-aware resolver should take a signature's validation period into consideration when determining the TTL of data in its cache, using the time remaining before RRSIG expiration as an upper bound for the cached RRset TTL.

dns, security

Because DNSSEC RRs can cause UDP message truncation and fallback to TCP, a security-aware name server must support the EDNS 'sender's UDP payload' mechanism.

dns, security

DNSSEC requires EDNS0 support (RFC 2671) to accommodate larger DNS message sizes resulting from the addition of DNSSEC resource records.

dns, security

Non-validating security-aware stub resolvers should use some form of channel security (e.g., TSIG, SIG(0), or IPsec) to defend against attacks on their communication with upstream recursive name servers.

dns, security

Security-aware resolvers must be capable of forming an authentication chain from a newly learned zone back to an authentication key, which may require additional queries for DNSKEY, DS, and RRSIG records.

dns, security

A Trust Anchor is a configured DNSKEY RR or DS RR hash of a DNSKEY RR that a validating resolver uses as the starting point for building an authentication chain. Trust anchors must be obtained via secure means outside the DNS protocol.

dns, security, crypto

An Authentication Chain is an alternating sequence of DNSKEY RRsets and DS RRsets, each link vouching for the next. The typical form is DNSKEY->[DS->DNSKEY]*->RRset, anchored at a configured trust anchor and terminating at the signed zone data.

dns, security, crypto

An Island of Security is a signed, delegated zone that lacks an authentication chain from its delegating parent (no DS RR in the parent zone). Responses from an island can only be authenticated via out-of-band means.

dns, security

DNSSEC adds four new resource record types—RRSIG (Resource Record Signature), DNSKEY (DNS Public Key), DS (Delegation Signer), and NSEC (Next Secure)—plus two new message header bits: CD (Checking Disabled) and AD (Authenticated Data).

dns, security

NSEC records provide authenticated denial of existence by linking existing names in canonical order and listing the RR types present at each name, thereby explicitly describing gaps between names in a zone.

dns, security

The Key Signing Key (KSK) signs one or more other authentication keys for a zone (typically the ZSK), while the Zone Signing Key (ZSK) signs zone data. This distinction is purely operational; DNSSEC validation does not differentiate between them, and a single key may serve both roles.

dns, security, crypto

DNSSEC does not protect against denial of service attacks and introduces new cryptographic DoS vectors: attackers can tamper with RRSIG RRs or construct complex signature chains to exhaust resolver resources, or flood a dynamic-update name server with updates to force excessive re-signing.

dns, security

DNSSEC introduces significant additional complexity and many new opportunities for implementation bugs and misconfiguration. Enabling DNSSEC signature validation in a resolver may cause entire legitimate zones to become unreachable due to configuration errors.

dns, security

For a security-aware resolver to validate a response, all zones along the path from the trust anchor to the response zone must be signed and all name servers and resolvers in the path must be security-aware. A break anywhere in the authentication chain prevents validation.

dns, security

Non-authoritative data at zone cuts (glue records and NS RRs in the parent zone) are not signed by DNSSEC, leaving them vulnerable to tampering during zone transfer operations even for otherwise fully signed zones.

dns, security

NSEC chains enable zone enumeration ('zone walking'): an attacker can query NSEC RRs in sequence to obtain all names in a signed zone, potentially mapping network hosts or resources. This is a direct consequence of the authenticated denial of existence mechanism.

dns, security, privacy

A validating resolver assigns one of four states to a DNS response: Secure (trust anchor, chain of trust, all signatures verified), Insecure (chain of trust with proven absence of DS at some delegation), Bogus (secure delegation exists but response fails validation), or Indeterminate (no applicable trust anchor).

dns, security