6. The AD and CD Bits and How to Resolve Securely
Retrieving or resolving authentic data from the Domain Name System (DNS) involves starting with one or more trusted public keys for one or more zones. With trusted keys, a resolver willing to perform cryptography can progress securely through the secure DNS zone structure to the zone of interest as described in Section 6.3. Such trusted public keys would normally be configured in a manner similar to that described in Section 6.2. However, as a practical matter, a security aware resolver would still gain some confidence in the results it returns even if it was not configured with any keys but trusted what it got from a local well known server as a starting point.
Data stored at a security aware server needs to be internally categorized as Authenticated, Pending, or Insecure. There is also a fourth transient state of Bad which indicates that all SIG checks have explicitly failed on the data. Such Bad data is not retained at a security aware server. Authenticated means that the data has a valid SIG under a KEY traceable via a chain of zero or more SIG and KEY RRs to a KEY configured at the resolver via its boot file. Pending data has no authenticated SIGs and at least one additional SIG the resolver is still trying to authenticate. Insecure data is data which it is known can never be either Authenticated or found Bad because it is in or has been reached via a non-secured zone. Behavior in terms of control of and flagging based on such data labels is described in Section 6.1.
The proper validation of signatures requires a reasonably secure shared opinion of the absolute time between resolvers and servers as described in Section 6.4.
6.1. The AD and CD Header Bits
Two previously unused bits are allocated out of the DNS query/response format header. The AD (authentic data) bit indicates in a response that the data included has been verified by the server providing it. The CD (checking disabled) bit indicates in a query that non-verified data is acceptable to the resolver sending the query.
These bits are allocated from the must-be-zero Z field as follows:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
These bits are zero in old servers and resolvers. Thus the responses of old servers are not flagged as authenticated to security aware resolvers and queries from non-security aware resolvers do not assert the checking disabled bit and thus will be answered by security aware servers only with authenticated data. Aware resolvers MUST not trust the AD bit unless they trust the server they are talking to and either have a secure path to it or use DNS transaction security.
Any security aware resolver willing to do cryptography SHOULD assert the CD bit on all queries to reduce DNS latency time by allowing security aware servers to answer before they have resolved the validity of data.
Security aware servers NEVER return Bad data. For non-security aware resolvers or security aware resolvers requesting service by having the CD bit clear, security aware servers MUST return only Authenticated or Insecure data with the AD bit set in the response. Security aware resolvers will know that if data is Insecure versus Authentic by the absence of SIG RRs. Security aware servers MAY return Pending data to security aware resolvers requesting the service by clearing the AD bit in the response. The AD bit MUST NOT be set on a response unless all of the RRs in the response are either Authenticated or Insecure.
6.2. Boot File Format
Two boot file directives are added as described in this section.
The format for a boot file directive to configure a starting zone key is as follows:
pubkey name flags protocol algorithm key-data
for a public key. "name" is the owner name (if the line is translated into a KEY RR). Flags indicates the type of key and is the same as the flag octet in the KEY RR. Protocol and algorithm also have the same meaning as they do in the KEY RR. The material after the algorithm is algorithm dependent and, for private algorithms (algorithm 254), starts with the algorithm's identifying OID and its length. If the "no key" type value is set in flags or the algorithm is specified as 253, then the key-data after algorithm is null. When present the key-data is treated as an octet stream and encoded in base 64 (see Appendix).
A file of keys for cross certification or other purposes can be configured though the keyfile directive as follows:
keyfile filename
The file looks like a master file except that it can only contain KEY and SIG RRs with the SIGs signed under a key configured with the pubkey directive.
While it might seem logical for everyone to start with the key for the root zone, this has problems. The logistics of updating every DNS resolver in the world when the root key changes would be excessive. It may be some time before there even is a root key. Furthermore, many organizations will explicitly wish their "interior" DNS implementations to completely trust only their own zone. Such interior resolvers can then go through the organization's zone servers to access data outsize the organization's domain and should only be configured with the key forthe organization's DNS apex.
6.3. Chaining Through Zones
Starting with one or more trusted keys for a zone, it should be possible to retrieve signed keys for its subzones which have a key and, if the zone is not root, for its superzone. Every authoritative secure zone server MUST also include the KEY RR for a super-zone signed by the secure zone via a keyfile directive. This makes it possible to climb the tree of zones if one starts below root. A secure sub-zone is indicated by a KEY RR with non-null key information appearing with the NS RRs for the sub-zone. These make it possible to descend within the tree of zones.
A resolver should keep track of the number of successive secure zones traversed from a starting point to any secure zone it can reach. In general, the lower such a distance number is, the greater the confidence in the data. Data configured via a boot file directive should be given a distance number of zero. If a query encounters different data for the same query with different distance values, that with a larger value should be ignored.
A security conscious resolver should completely refuse to step from a secure zone into a non-secure zone unless the non-secure zone is certified to be non-secure, or only experimentally secure, by the presence of an authenticated KEY RR for the non-secure zone with the no-key type value or the presence of a KEY RR with the experimental bit set. Otherwise the resolver is getting bogus or spoofed data.
If legitimate non-secure zones are encountered in traversing the DNS tree, then no zone can be trusted as secure that can be reached only via information from such non-secure zones. Since the non-secure zone data could have been spoofed, the "secure" zone reach via it could be counterfeit. The "distance" to data in such zones or zones reached via such zones could be set to 512 or more as this exceeds the largest possible distance through secure zones in the DNS. Nevertheless, continuing to apply secure checks within "secure" zones reached via non-secure zones is a good practice and will, as a practical matter, provide some small increase in security.
6.4. Secure Time
Coordinated interpretation of the time fields in SIG RRs requires that reasonably consistent time be available to the hosts implementing the DNS security extensions.
A variety of time synchronization protocols exist including the Network Time Protocol (NTP, RFC1305draft). If such protocols are used, they MUST be used securely so that time can not be spoofed. Otherwise, for example, a host could get its clock turned back and might then believe old SIG and KEY RRs which were valid but no longer are.