Skip to main content

3. Serving

This section describes the behavior of entities that include security-aware name server functions. In many cases such functions will be part of a security-aware recursive name server, but a security-aware authoritative name server has some of the same requirements.

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

A security-aware name server that receives a DNS query that does not include the EDNS OPT pseudo-RR or that has the DO bit clear MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and MUST NOT perform any of the additional processing described below.

DNSSEC allocates two new bits in the DNS message header:

  • CD (Checking Disabled) bit: Controlled by resolvers
  • AD (Authentic Data) bit: Controlled by name servers

A security-aware name server MUST copy the CD bit from a query into the corresponding response. A security-aware name server MUST ignore the setting of the AD bit in queries.

3.1. Authoritative Name Servers​

Upon receiving a relevant query that has the EDNS OPT pseudo-RR DO bit set, a security-aware authoritative name server for a signed zone MUST include additional RRSIG, NSEC, and DS RRs, according to the following rules:

  • RRSIG RRs that can be used to authenticate a response MUST be included in the response according to the rules in Section 3.1.1
  • NSEC RRs that can be used to provide authenticated denial of existence MUST be included in the response automatically according to the rules in Section 3.1.3
  • Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST be included in referrals automatically according to the rules in Section 3.1.4

3.1.1. Including RRSIG RRs in a Response​

When responding to a query that has the DO bit set, a security-aware authoritative name server SHOULD attempt to send RRSIG RRs that a security-aware resolver can use to authenticate the RRsets in the response.

Rules:

  • When placing a signed RRset in the Answer section, the name server MUST also place its RRSIG RRs in the Answer section
  • When placing a signed RRset in the Authority section, the name server MUST also place its RRSIG RRs in the Authority section
  • When placing a signed RRset in the Additional section, the name server MUST also place its RRSIG RRs in the Additional section
  • If space does not permit inclusion of RRSIG RRs in Answer or Authority sections, the name server MUST set the TC bit

3.1.2. Including DNSKEY RRs in a Response​

When responding to a query that has the DO bit set and that requests the SOA or NS RRs at the apex of a signed zone, a security-aware authoritative name server for that zone MAY return the zone apex DNSKEY RRset in the Additional section.

The DNSKEY RRset and associated RRSIG RRs have lower priority than does any other information that would be placed in the additional section.

3.1.3. Including NSEC RRs in a Response​

When responding to a query that has the DO bit set, a security-aware authoritative name server for a signed zone MUST include NSEC RRs in each of the following cases:

No Data: The zone contains RRsets that exactly match <SNAME, SCLASS> but does not contain any RRsets that exactly match <SNAME, SCLASS, STYPE>.

Name Error: The zone does not contain any RRsets that match <SNAME, SCLASS> either exactly or via wildcard name expansion.

Wildcard Answer: The zone does not contain any RRsets that exactly match <SNAME, SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> via wildcard name expansion.

Wildcard No Data: The zone does not contain any RRsets that exactly match <SNAME, SCLASS> and does contain one or more RRsets that match <SNAME, SCLASS> via wildcard name expansion, but does not contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard name expansion.

3.1.3.1. Including NSEC RRs: No Data Response​

If the zone contains RRsets matching <SNAME, SCLASS> but contains no RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST include the NSEC RR for <SNAME, SCLASS> along with its associated RRSIG RR(s) in the Authority section.

3.1.3.2. Including NSEC RRs: Name Error Response​

If the zone does not contain any RRsets matching <SNAME, SCLASS> either exactly or via wildcard name expansion, then the name server MUST include the following NSEC RRs in the Authority section:

  • An NSEC RR proving that there is no exact match for <SNAME, SCLASS>
  • An NSEC RR proving that the zone contains no RRsets that would match <SNAME, SCLASS> via wildcard name expansion

3.1.3.3. Including NSEC RRs: Wildcard Answer Response​

If the zone does not contain any RRsets that exactly match <SNAME, SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE> via wildcard name expansion, the name server MUST include the wildcard-expanded answer and the corresponding wildcard-expanded RRSIG RRs in the Answer section and MUST include in the Authority section an NSEC RR proving that the zone does not contain a closer match.

3.1.3.4. Including NSEC RRs: Wildcard No Data Response​

The name server MUST include the following NSEC RRs in the Authority section:

  • An NSEC RR proving that there are no RRsets matching STYPE at the wildcard owner name
  • An NSEC RR proving that there are no RRsets in the zone that would have been a closer match

3.1.4. Including DS RRs in a Response​

DS RRs are only present at delegation points. The DS RR at a delegation point establishes the authentication chain into the child zone. A security-aware name server returning a referral MUST attempt to return the DS RRset along with its associated RRSIG RR(s) in the Authority section.

If a DS RRset does not exist at the delegation point, the name server MUST return an NSEC RR that proves that the DS RRset does not exist.

3.1.5. Responding to Queries for Type AXFR or IXFR​

DNSSEC does not change the DNS zone transfer protocol. A security-aware authoritative name server MUST include the appropriate DNSSEC RRs (RRSIG, NSEC, DS, and DNSKEY RRs) in zone transfers.

3.1.6. The AD and CD Bits in an Authoritative Response​

A security-aware authoritative name server MUST clear the AD bit in responses unless the name server is both authoritative for the zone that contains all RRsets in the Answer and Authority sections and all necessary RRSIG and NSEC RRs are included.

A security-aware authoritative name server MUST copy the CD bit from the query to the response.

3.2. Recursive Name Servers​

A security-aware recursive name server is an entity that acts as a security-aware resolver (see Section 4) and also provides security-aware query service to other resolvers or stub resolvers.

3.2.1. The DO Bit​

A security-aware recursive name server MUST set the DO bit in queries it sends to authoritative name servers when the DO bit was set in the query received by the recursive name server.

3.2.2. The CD Bit​

The CD (Checking Disabled) bit controls whether a security-aware recursive name server performs DNSSEC validation. When the CD bit is set, a security-aware recursive name server SHOULD NOT perform DNSSEC validation but SHOULD still fetch DNSSEC RRs.

3.2.3. The AD Bit​

The AD (Authentic Data) bit indicates whether the data in the Answer and Authority sections has been verified by a security-aware resolver in accordance with the policies of that resolver's local security policy.

A security-aware recursive name server MUST set the AD bit in a response if:

  • The RRsets in the Answer and Authority sections were successfully validated
  • Or the response was received with the AD bit set from an upstream server that is trusted

3.3. Example DNSSEC Responses​

Appendix B contains detailed examples of DNSSEC responses for various scenarios including:

  • Positive answers
  • Name errors
  • No data errors
  • Referrals to signed and unsigned zones
  • Wildcard expansions
Last updated on