DNSSEC explicitly does not provide confidentiality (query/response privacy), access control, or denial-of-service protection, following the DNS design philosophy that data is public and the same answers are given to all inquirers. These services may be obtained via IPsec, TLS, or other security protocols.

dns, security, privacy

Signature expiration and inception times use 32-bit unsigned seconds-since-epoch with ring arithmetic (as in SOA serial numbers), making them ambiguous modulo ~136 years. This is acceptable because RFC 2541 requires keys to be replaced at least every five years, making reuse of the same key after 136 years negligibly probable.

dns, security, crypto

The 'original TTL' is included in the SIG RDATA and protected by the signature to prevent caching servers from decrementing the TTL in a way that breaks signature verification, while also preventing unscrupulous servers from setting arbitrarily long TTL values undetected. The current TTL is still transmitted but is bounded by the original signed value at security-aware resolvers.

dns, security

Request SIGs (type-covered = 0 on a query) are unnecessary for any currently defined request other than dynamic update and will cause some legacy DNS servers to return errors or ignore the query. Servers are not required to check request SIGs except where needed to authenticate an update or similarly privileged request.

dns, security

DSA (algorithm 3) is the mandatory-to-implement algorithm for KEY and SIG RRs. RSA/MD5 (algorithm 1) is recommended. An appropriate zone KEY RR MUST occur at the apex node of a secure zone.

dns, security, crypto

Security-aware resolvers MUST NOT trust the AD bit unless they trust the server they are communicating with and either have a secure path to it or use DNS transaction security.

dns, security

Security-aware servers MUST allow KEY, SIG, and NXT RRs to coexist with CNAME RRs, MUST suppress CNAME processing on retrieval of those types, and MUST automatically return SIG RRs authenticating any CNAMEs encountered. This overrides the prior prohibition on other RR types at a CNAME node.

dns, security

Security-aware servers MUST NOT consider SIG RRs to authenticate anything before their signature inception or after their expiration time, and MUST NOT consider any RR authenticated after all its signatures have expired. TTLs in cached entries SHOULD be trimmed not to extend beyond the authentication expiration time.

dns, security

Security-aware servers MUST NOT return Bad data (data for which all SIG checks have explicitly failed). For resolvers that do not set the CD bit, servers MUST return only Authenticated or Insecure data in answer and authority sections. The AD bit MUST NOT be set unless all answer and authority RRs are either Authenticated or Insecure.

dns, security

SIGs to authenticate glue records and NS RRs for subzones at a delegation point are unnecessary and MUST NOT be sent.

dns, security

There MUST be a zone KEY RR, signed by its superzone, for every subzone if the superzone is secure. If an unsecured subzone will not add security RRs, a KEY RR declaring it unsecured MUST appear with the superzone signature in the superzone.

dns, security

When including SIG RRs in responses, if a SIG covers an RR in the answer section but space is insufficient to include it, the response MUST be considered truncated (with the exception that truncation MUST NOT be declared solely because a SIG for an additional-information RR did not fit).

dns, security

Data at a security-aware server is internally categorized as Authenticated (valid SIG traceable to a trusted key), Pending (no authenticated SIGs but at least one under evaluation), Insecure (in or reached via an unsecured zone, or unsigned glue/delegation NS data), or Bad (all SIG checks explicitly failed; not retained).

dns, security

For DNS security, the canonical form of an RR is its wire format with domain names fully expanded (no compression pointers), all domain name letters lowercased, wildcard owner names left as '*' without substitution, and the original TTL substituted for the current TTL. Canonical DNS name ordering sorts labels as unsigned left-justified octet strings with absence before zero.

dns, security

Resolver signing-policy rules define when a signer name is valid for authenticating an RRset: (1) Owner is the same as or a subdomain of Signer (descending the tree); (2) Owner is a superdomain of Signer and Signer is statically configured or its subdomain (ascending from trusted keys); (3) Signer exactly matches a statically configured key (cross-certification).

dns, security

The KEY resource record (type 25) stores a public key associated with a DNS name. Its RDATA consists of a 16-bit flags field, a protocol octet, an algorithm octet, and a variable-length public key. Security-aware implementations MUST handle at least two simultaneously valid keys of the same type for the same name.

dns, security, crypto

The key tag field (2 octets) enables efficient selection among multiple candidate keys before the expensive signature check. For RSA/MD5 it is the most significant 16 of the least significant 24 bits of the public modulus; for all other algorithms it is a simple checksum of the KEY RR as specified in Appendix C.

dns, security, crypto

The NXT RR (type 30) provides authenticated denial of existence by creating a chain of all literal owner names in a zone in canonical order. Its RDATA points to the next owner name in that order and carries a bit map of RR types present at the current owner. The zone name is placed in the RDATA of the last NXT to make the chain circular.

dns, security

The SIG RR 'labels' field is an unsigned count of labels in the original owner name, excluding the root null label and any leading wildcard '*'. If the retrieved owner name has more labels than this count, the RR is a wildcard expansion; if it has fewer, the SIG is corrupt and must be ignored.

dns, security

The SIG RR with type-covered field of zero is a transaction authentication signature. It is calculated over the concatenation of the full DNS response (excluding the transaction SIG itself) and the full DNS query that produced it, and is placed at the end of the additional information section.

dns, security, crypto

Two DNS header bits are defined: AD (Authentic Data, bit 10) indicates in a response that all answer and authority RRs have been authenticated by the server; CD (Checking Disabled, bit 11) indicates in a query that Pending (non-authenticated) data is acceptable to the requesting resolver.

dns, security

The KEY RR algorithm number registry assigns: 0 (reserved), 1 (RSA/MD5, recommended), 2 (Diffie-Hellman, optional, key only), 3 (DSA, MANDATORY), 4 (reserved for elliptic curve), 252 (indirect keys), 253 (private, domain name), 254 (private, OID), 255 (reserved). Values 5–251 are available for IANA assignment.

dns, security, registry, crypto

The KEY RR protocol octet registry assigns: 0 (reserved), 1 (TLS), 2 (email), 3 (DNSSEC), 4 (IPSEC/Oakley), 255 (All protocols). Values 5–254 are available for IANA assignment. Use of value 255 is discouraged; separate keys per protocol are preferred.

dns, security, registry

A security-conscious resolver SHOULD refuse to step from a secure zone into an unsecured zone unless an authenticated 'no-key' KEY RR certifies the zone is intentionally unsecured. Traversal through unsecured zones taints all downstream data, since spoofed unsecured-zone data could redirect resolution to counterfeit 'secure' zones.

dns, security

Secure time is essential: if a resolver's clock is spoofed backward, it may accept expired SIG RRs and the stale data they authenticate. Time synchronization protocols such as NTP MUST themselves be used securely to prevent clock manipulation from undermining DNSSEC signature validity checks.

dns, security, ntp

A zone's secure status for a given algorithm is determined by the trusted zone KEY RRs: (1) if all trusted zone KEY RRs assert no-key, the zone is Unsecured; (2) if there is at least one trusted no-key and one key-specifying RR, the zone is Experimentally Secure; (3) if all trusted zone KEY RRs are key-specifying, the zone is Secure and only authenticated RRs are accepted.

dns, security

KEY RR RDATA: 16-bit flags field (authentication/confidentiality use bits, name type bits, signatory bits), 8-bit protocol octet, 8-bit algorithm octet, followed by variable-length public key material. If the 'no key' flag (bits 0 and 1 both set) is present, the RR ends after the algorithm octet.

dns, security, crypto

NXT RR RDATA (type 30): a variable-length next domain name in wire format followed by a type bit map. Each bit in the bit map represents one RR type present at the owner name; bit 30 (NXT) is always set. Trailing zero octets are prohibited. If any RR type number exceeds 127, an alternate format is indicated by setting the zero bit.

dns, security

SIG RR RDATA (type 24): 16-bit type covered, 8-bit algorithm, 8-bit labels count, 32-bit original TTL, 32-bit signature expiration, 32-bit signature inception (seconds since 1970-01-01), 16-bit key tag, variable-length signer's name (wire-encoded domain name), and variable-length signature.

dns, security, crypto