There have been a number of security extensions proposed for possible implementation by DNS servers and many of these ideas are documented in RFC 2065. The primary concerns addressed by the proposed security extensions are to allow the DNS infrastructure to have a method of verifying the integrity of the record being served, in addition to verifying the actual identity of servers claiming to be authoritive DNS servers. A second feature of the security extensions is to allow DNS to be used as a central distribution method for public-keys.
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.
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.
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.
| Signature (SIG) record | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The SIG or "signature" resource record (RR) is the fundamental way that data is authenticated in the secure Domain Name System (DNS). As such it is the heart of the security provided. The SIG RR unforgably authenticates other RRs of a particular type, class, and name and binds them to a time interval and the signer's domain name. This is done using cryptographic techniques and the signer's private key. The signer is frequently the owner of the zone from which the RR originated. The syntax of a SIG resource record (signature) 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. The shorter of the "original TTL" and the "current TTL" (determined by comparing the current absolute time to the "expiration time") is the value that is actually used by the downstream DNS client/server when deciding how long to cache the signature.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type covered | algorithm | labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time signed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key footprint | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
+- signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "type covered" is the type of the other RRs covered by this SIG. Algorithm is merely a number indicating the signature algorithm that is being used. The values are currently assigned as follows:
The expiration values are measured in seconds. The "time signed" and "signature expiration" are absolute timestamps measures in seconds from 1970. The "key footprint" is a 16 bit quantity that is used to help efficiently select between multiple keys which may be applicable and as a quick check that a public key about to be used for the computationally expensive effort to check the signature is possibly valid. Its exact meaning is algorithm dependent. For the MD5/RSA algorithm, it is the next to the bottom two octets of the public key modulus needed to decode the signature field. That is to say, the most significant 16 of the lest significant 24 bits of the modulus in network order. The "signature" area is how the SIG RR binds the other RDATA fields to all of the "type covered" RRs with that owner name and class. These covered RRs are thereby authenticated. To accomplish this, a data sequence is merely all the RDATA fields in the SIG RR itself, and then all the RR(s) of the type covered with the same owner name and class as the SIG RR in canonical form and order. How this data sequence is processed into the signature is algorithm dependent. |
| Zone Transfer (AXFR) SIG |
|---|
|
To efficiently assure the completeness and security of zone transfers, a SIG RR owned by the zone name must be created with a type covered of AXFR that covers all zone signed RRs in the zone and their zone SIGs but not the SIG AXFR itself. The AXFR SIG must be calculated last of all zone key signed SIGs in the zone. In effect, when signing the zone, you order, as described above, all RRs to be signed by the zone, and all associated glue RRs and delegation point NS RRs. You can then make one pass inserting all the zone SIGs. As you proceed you hash RRs to be signed into both an RRset hash and the zone hash. When the name or type changes you calculate and insert the RRset zone SIG, clear the RRset hash, and hash that SIG into the zone hash (note that glue RRs and delegation point NSs are not zone signed but zone apex NSs are). When you have finished processing all the starting RRs as described above, you can then use the cumulative zone hash RR to calculate and insert an AXFR SIG covering the zone. Of course any computational technique producing the same results as above is permitted. |
| Key (KEY) Record |
|---|
|
The KEY resource record (RR) is used to document a key that is associated with a Domain Name System (DNS) name. It will be a public key as only public keys are stored in the DNS. This can be the public key of a zone, a host or other end entity, or a user. A KEY RR is, like any other RR, authenticated by a SIG RR. Security aware DNS implementations MUST be designed to handle at least two simultaneously valid keys of the same type associated with a name. |
There is also a NXT (non-existence) record that is defined to allowed communication of the fact that a particular record does not exist. The "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.
DNSSEC is not supported in any significant implementation today. The latest version of BIND does not offer any of the DNS Security extensions proposed by either of the two RFC's covering this area. The Internet Software Corsorium (makers of BIND) announced an alliance with RSA Data Securities to produce a secure version of bind in their announcement made in October 1997 indicating that they had planned to have a beta version of DNSsafe available before the end of that year, but no further news regarding this has been made available.
A prototype version of a secure DNS server was implemented by Trusted Information Systems, which can be used to run a secure DNS server for testing purposes. However, the effort to maintain this source pool has since died off and the source hasn't been updated since Jan 1997.
The Domain Name System Security Page has a collection of useful links related to DNS security implementations and its current level of support in BIND.
The two primary RFC's that specify the DNSSEC protocol and its implementation are RFC 2065 - Domain Name System Security Extensions and RFC 2137 - Secure Domain Name System Dynamic Update.