2. Overview of the DNS Extensions
The Domain Name System (DNS) protocol security extensions provide three distinct services: key distribution as described in Section 2.2 below, data origin authentication as described in Section 2.3 below, and transaction and request authentication, described in Section 2.4 below.
Special considerations related to "time to live", CNAMEs, and delegation points are also discussed in Section 2.3.
2.1. Services Not Provided
It is part of the design philosophy of the DNS that the data in it is public and that the DNS gives the same answers to all inquirers.
Following this philosophy, no attempt has been made to include any sort of access control lists or other means to differentiate inquirers.
In addition, no effort has been made to provide for any confidentiality for queries or responses. (This service may be available via IPSEC [RFC1825].)
2.2. Key Distribution
Resource records (RRs) are defined to associate keys with DNS names. This permits the DNS to be used as a public key distribution mechanism in support of the DNS data origin authentication and other security services.
The syntax of a KEY resource record (RR) is described in Section 3. It includes an algorithm identifier, the actual public key parameters, and a variety of flags including those indicating the type of entity the key is associated with and/or asserting that there is no key associated with that entity.
Under conditions described in Section 3.7, security aware DNS servers will automatically attempt to return KEY resources as additional information, along with those resource records actually requested, to minimize the number of queries needed.
2.3. Data Origin Authentication and Integrity
Authentication is provided by associating with resource records in the DNS cryptographically generated digital signatures. Commonly, there will be a single private key that signs for an entire zone. If a security aware resolver reliably learns the public key of the zone, it can verify, for signed data read from that zone, that it was properly authorized and is reasonably current. The expected implementation is for the zone private key to be kept off-line and used to re-sign all of the records in the zone periodically.
This data origin authentication key belongs to the zone and not to the servers that store copies of the data. That means compromise of a server or even all servers for a zone will not necessarily affect the degree of assurance that a resolver has that it can determine whether data is genuine.
A resolver can learn the public key of a zone either by reading it from DNS or by having it staticly configured. To reliably learn the public key by reading it from DNS, the key itself must be signed. Thus, to provide a reasonable degree of security, the resolver must be configured with at least the public key of one zone that it can use to authenticate signatures. From there, it can securely read the public keys of other zones, if the intervening zones in the DNS tree are secure and their signed keys accessible. (It is in principle more secure to have the resolver manually configured with the public keys of multiple zones, since then the compromise of a single zone would not permit the faking of information from other zones. It is also more administratively cumbersome, however, particularly when public keys change.)
Adding data origin authentication and integrity requires no change to the "on-the-wire" DNS protocol beyond the addition of the signature resource type and, as a practical matter, the key resource type needed for key distribution. This service can be supported by existing resolver and server implementations so long as they can support the additional resource types (see Section 8). The one exception is that CNAME referrals from a secure zone can not be authenticated if they are from non-security aware servers (see Section 2.3.5).
If signatures are always separately retrieved and verified when retrieving the information they authenticate, there will be more trips to the server and performance will suffer. To avoid this, security aware servers mitigate that degradation by always attempting to send the signature(s) needed.
2.3.1. The SIG Resource Record
The syntax of a SIG resource record (signature) is described in Section 4. It includes the type of the RR(s) being signed, the name of the signer, the time at which the signature was created, the time it expires (when it is no longer to be believed), its original time to live (which may be longer than its current time to live but cannot be shorter), the cryptographic algorithm in use, and the actual signature.
Every name in a secured zone will have associated with it at least one SIG resource record for each resource type under that name except for glue RRs and delgation point NS RRs. A security aware server supporting the performance enhanced version of the DNS protocol security extensions will attempt to return, with RRs retrieved, the corresponding SIGs. If a server does not support the protocol, the resolver must retrieve all the SIG records for a name and select the one or ones that sign the resource record(s) that resolver is interested in.
2.3.2. Authenticating Name and Type Non-existence
The above security mechanism provides only a way to sign existing RRs in a zone. "Data origin" authentication is not obviously provided for the non-existence of a domain name in a zone or the non-existence of a type for an existing name. This gap is filled by the NXT RR which authenticatably asserts a range of non-existent names in a zone and the non-existence of types for the name just before that range.
Section 5 below covers the NXT RR.
2.3.3. Special Considerations With Time-to-Live
A digital signature will fail to verify if any change has occurred to the data between the time it was originally signed and the time the signature is verified. This conflicts with our desire to have the time-to-live field tick down when resource records are cached.
This could be avoided by leaving the time-to-live out of the digital signature, but that would allow unscrupulous servers to set arbitrarily long time to live values undetected. Instead, we include the "original" time-to-live in the signature and communicate that data in addition to the current time-to-live. Unscrupulous servers under this scheme can manipulate the time to live but a security aware resolver will bound the TTL value it uses at the original signed value. Separately, signatures include a time signed and an expiration time. A resolver that knows the absolute time can determine securely whether a signature has expired. It is not possible to rely solely on the signature expiration as a substitute for the TTL, however, since the TTL is primarily a database consistency mechanism and, in any case, non-security aware servers that depend on TTL must still be supported.
2.3.4. Special Considerations at Delegation Points
DNS security would like to view each zone as a unit of data completely under the control of the zone owner and signed by the zone's key. But the operational DNS views the leaf nodes in a zone, which are also the apex nodes of a subzone (i.e., delegation points), as "really" belonging to the subzone. These nodes occur in two master files and may have RRs signed by both the upper and lower zone's keys. A retrieval could get a mixture of these RRs and SIGs, especially since one server could be serving both the zone above and below a delegation point.
In general, there must be a zone KEY RR for the subzone in the superzone and the copy signed in the superzone is controlling. For all but one other RR type that should appearing in both the superzone and subzone, the data from the subzone is more authoritative. To avoid conflicts, only the KEY RR in the superzone should be signed and the NS and any A (glue) RRs should only be signed in the subzone. The SOA and any other RRs that have the zone name as owner should appear only in the subzone and thus are signed there. The NXT RR type is an exceptional case that will always appear differently and authoritatively in both the superzone and subzone, if both are secure, as described in Section 5.
2.3.5. Special Considerations with CNAME RRs
There is a significant problem when security related RRs with the same owner name as a CNAME RR are retrieved from a non-security-aware server. In particular, an initial retrieval for the CNAME or any other type will not retrieve any associated signature, key, or NXT RR. For types other than CNAME, it will retrieve that type at the target name of the CNAME (or chain of CNAMEs) and will return the CNAME as additional information. In particular, a specific retrieval for type SIG will not get the SIG, if any, at the original CNAME domain name but rather a SIG at the target name.
In general, security aware servers MUST be used to securely CNAME in DNS. Security aware servers must (1) allow KEY, SIG, and NXT RRs along with CNAME RRs, (2) suppress CNAME processing on retrieval of these types as well as on retrieval of the type CNAME, and (3) automatically return SIG RRs authenticating the CNAME or CNAMEs encountered in resolving a query. This is a change from the previous DNS standard which prohibited any other RR type at a node where a CNAME RR was present.
2.3.6. Signers Other Than The Zone
There are two cases where a SIG resource record is signed by other than the zone private key. One is for support of dynamic update where an entity is permitted to authenticate/update its own records. The public key of the entity must be present in the DNS and be appropriately signed but the other RR(s) may be signed with the entity's key. The other is for support of transaction and request authentication as described in Section 2.4 immediately below.
2.4. DNS Transaction and Request Authentication
The data origin authentication service described above protects retrieved resource records but provides no protection for DNS requests or for message headers.
If header bits are falsely set by a server, there is little that can be done. However, it is possible to add transaction authentication. Such authentication means that a resolver can be sure it is at least getting messages from the server it thinks it queried, that the response is from the query it sent, and that these messages have not been diddled in transit. This is accomplished by optionally adding a special SIG resource record at the end of the reply which digitally signs the concatenation of the server's response and the resolver's query.
Requests can also be authenticated by including a special SIG RR at the end of the request. Authenticating requests serves no function in the current DNS and requests with a non-empty additional information section are ignored by almost all current DNS servers. However, this syntax for signing requests is defined in connection with authenticating future secure dynamic update requests or the like.
The private keys used in transaction and request security belongs to the host composing the request or reply message, not to the zone involved. The corresponding public key is normally stored in and retrieved from the DNS.
Because requests and replies are highly variable, message authentication SIGs can not be pre-calculated. Thus it will be necessary to keep the private key on-line, for example in software or in a directly connected piece of hardware.