NSEC records MUST NOT be created for owner name nodes that did not exist before the zone was signed. The reasons are to maintain namespace consistency between signed and unsigned versions of the same zone and to reduce the risk of response inconsistency in security-oblivious recursive name servers.

dns, security

The absence of DNSSEC data in a response MUST NOT by itself be taken as an indication that no authentication information exists, because an adversary could forge a response, strip DNSSEC RRs, or modify a query so that DNSSEC RRs appear not to be requested.

dns, security

If a CNAME RRset is present at a name in a signed zone, appropriate RRSIG and NSEC RRsets are REQUIRED at that name. This modifies the original CNAME definition in RFC 1034, which prohibited any other RR types from coexisting with a CNAME record.

dns

A security-aware name server MUST NOT set the AD bit in a response unless it considers all RRsets in the Answer and Authority sections to be authentic and MUST NOT assert authenticity of authoritative-zone data unless the zone was obtained via secure means (such as secure zone transfer) and that behavior is explicitly configured.

dns, security

A security-aware name server MUST support the EDNS0 message size extension, MUST support a message size of at least 1220 octets, and SHOULD support a message size of 4000 octets.

dns, security

A security-aware name server that receives a DNS query without the EDNS OPT pseudo-RR or with the DO bit clear MUST treat RRSIG, DNSKEY, and NSEC RRs as any other RRset and MUST NOT perform any of the additional DNSSEC processing described in Section 3.

dns, security

A security-aware resolver can use an RRSIG RR to authenticate an RRset only when: the RRSIG and RRset share owner name and class; Signer's Name is the zone containing the RRset; Type Covered matches; label count is valid; current time falls within Inception and Expiration; and a matching DNSKEY RR with the Zone Flag bit set exists at the zone apex.

dns, security, crypto

A security-aware resolver MUST be capable of being configured with at least one trusted public key or DS RR (trust anchor) and SHOULD be capable of being configured with multiple trust anchors. The resolver SHOULD have a robust mechanism for obtaining such keys when it boots.

dns, security

A security-aware resolver MUST include an EDNS OPT pseudo-RR with the DO bit set when sending queries, MUST support a message size of at least 1220 octets, and MUST use the 'sender's UDP payload size' field to advertise the message size it is willing to accept.

dns, security

A security-aware resolver MUST support the signature verification mechanisms described in Section 5 and SHOULD apply them to every received response except when: the CD bit was set in the query, the application instructed no validation, or local policy disables validation. Wildcard owner name verification MUST be supported.

dns, security, crypto

A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer including the named RRset and any associated DNSSEC RRs, and SHOULD discard the entire atomic entry when any of the RRs contained in it expire.

dns, security

A signed zone MUST include DNSKEY, RRSIG, NSEC, and optionally DS resource records according to the rules in Section 2. A zone that does not include these records according to those rules is an unsigned zone.

dns, security

An RRSIG RR itself MUST NOT be signed. The NS RRset at the zone apex MUST be signed, but NS RRsets at delegation points and glue address RRsets MUST NOT be signed.

dns, security

Each owner name in the zone that has authoritative data or a delegation point NS RRset MUST have an NSEC resource record. An NSEC record (and its associated RRSIG RRset) MUST NOT be the only RRset at any particular owner name.

dns, security

For each authoritative RRset in a signed zone there MUST be at least one RRSIG record whose owner name, class, type, TTL, Labels field, Signer's Name, algorithm, and Key Tag all match the RRset and identify a zone key DNSKEY record at the zone apex.

dns, security

If a validator accepts an RRset as authentic, it MUST set the TTL of the RRSIG RR and each RR in the authenticated RRset to a value no greater than the minimum of: the received RRset TTL, the received RRSIG TTL, the RRSIG Original TTL field, and the difference between the RRSIG Signature Expiration time and the current time.

dns, security

If none of the RRSIGs for a response can be validated, the response SHOULD be considered BAD. If validation was performed to service a recursive query, the name server MUST return RCODE 2 (server failure) to the originating client but MUST return the full response if and only if the original query had the CD bit set.

dns, security

The resolver side of a security-aware recursive name server MUST set the DO bit when sending requests, regardless of the DO bit in the initiating request. If the initiating query's DO bit is not set, the name server side MUST strip authenticating DNSSEC RRs from the response, except for DNSSEC RR types that the initiating query explicitly requested.

dns, security

When placing a signed RRset in the Answer or Authority section, a name server MUST also place its RRSIG RRs in that same section, with higher priority than any other RRsets; if space does not permit, the name server MUST set the TC bit. In the Additional section, the name server MAY drop RRSIG RRs without setting TC.

dns, security

When responding to a query with the DO bit set, a security-aware authoritative name server MUST include NSEC RRs in four cases: No Data (name exists but type absent), Name Error (name absent), Wildcard Answer, and Wildcard No Data, to prove that an exact match was not present.

dns, security

When returning a referral in response to a query with the DO bit set, a security-aware authoritative name server MUST include the DS RRset and its RRSIG(s) if present at the delegation point, or MUST include the NSEC RR and RRSIG(s) proving no DS RRset exists.

dns, security

When the CD bit is set in a query, a recursive name server SHOULD return requested data to the originating resolver even if the server's local authentication policy would reject the records, because the originating resolver has taken responsibility for performing its own authentication.

dns, security

A security-aware resolver MUST distinguish four security statuses for an RRset: Secure (valid chain of signed DNSKEY/DS from a trust anchor), Insecure (no chain from any trusted starting point), Bogus (chain should exist but cannot be established), and Indeterminate (cannot determine if the RRset should be signed).

dns, security

Authenticated denial of existence uses NSEC RRs: if the queried name matches an NSEC owner name, the type bitmap proves which types are absent; if the name falls canonically between an NSEC owner name and its Next Domain Name field, no RRsets with that name exist — but proving no wildcard match exists may require additional NSEC RRs.

dns, security

DNSSEC allocates two new DNS message header bits: the CD (Checking Disabled) bit, controlled by resolvers, which a security-aware name server MUST copy from a query into the corresponding response; and the AD (Authentic Data) bit, controlled by name servers, which a security-aware name server MUST ignore when set in a query.

dns, security

Security-aware resolvers MAY maintain a 'BAD cache' of data with invalid signatures. Resolvers implementing a BAD cache MUST assign a short TTL to such entries and SHOULD only answer from the BAD cache after the count of validation failures for a given <QNAME, QTYPE, QCLASS> exceeds a threshold, to prevent denial-of-service amplification.

dns, security

The DS resource record type appears only on the parent zone's side of a zone cut. When a security-aware name server is authoritative only for the child zone and receives a DS query it cannot answer, it MUST return an authoritative 'no data' response showing the DS RRset does not exist in the child zone's apex.

dns, security

This document restates the meaning of the CD (Checking Disabled) and AD (Authentic Data) bits in the DNS message header, originally reserved by RFC 2535 with the AD bit redefined by RFC 3655. No new DNS message header bits are defined in this document. The DNSSEC OK (DO) bit use, introduced by RFC 2671 and reserved by RFC 3225, is also restated without alteration.

dns, registry

An active attacker who can set the CD bit in a DNS query or the AD bit in a DNS response can defeat the protection DNSSEC attempts to provide to security-oblivious recursive-mode resolvers. Use of these control bits by a security-aware recursive-mode resolver therefore requires a secure channel.

dns, security

Recovery from DNSSEC validation failures is likely to be specific to particular applications, and the facilities DNSSEC provides for stub resolvers may prove inadequate. Operators of security-aware recursive name servers must carefully choose local validation policy to avoid accidentally denying service to the clients they support.

dns, security

The original signed data is reconstructed as: RRSIG_RDATA (excluding Signature field, Signer's Name in canonical form) concatenated with each RR in canonical form (name | type | class | OrigTTL | RDATA length | RDATA), where all names in RDATA are in canonical form, TTL is taken from the RRSIG Original TTL field, and the RR set is sorted in canonical order.

dns, security, crypto