4. The SIG Resource 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.
4.1. SIG RDATA Format
The RDATA portion of a SIG RR is as shown below. The integrity of the RDATA information is protected by the signature field.
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 value of the SIG RR type is 24.
The "type covered" is the type of the other RRs covered by this SIG.
The algorithm number is an octet specifying the digital signature algorithm used parallel to the algorithm octet for the KEY RR. The MD5/RSA algorithm described in this document is number 1. Numbers 2 through 252 are available for assignment should sufficient reason arise to allocate them. However, the designation of a new algorithm could have a major impact on the interoperability of the global DNS system and requires an IETF standards action. Number 254 is reserved for private use and will not be assigned a specific algorithm. For number 254, the "signature" area shown above will actually begin with a length byte followed by an Object Identifier (OID) of that length. The OID indicates the private algorithm in use and the remainder of the area is whatever is required by that algorithm. Number 253, known as the "expiration date algorithm", is used when the expiration date or other non-signature fields of the SIG are desired without any actual security. It is anticipated that this algorithm will only be used in connection with some modes of DNS dynamic update. For number 253, the signature field will be null. Values 0 and 255 are reserved.
The "labels" octet is an unsigned count of how many labels there are in the original SIG RR owner name not counting the null label for root and not counting any initial "*" for a wildcard. If a secured retrieval is the result of wild card substitution, it is necessary for the resolver to use the original form of the name in verifying the digital signature. This field helps optimize the determination of the original form thus reducing the effort in authenticating signed data.
If, on retrieval, the RR appears to have a longer name than indicated by "labels", the resolver can tell it is the result of wildcard substitution. If the RR owner name appears to be shorter than the labels count, the SIG RR must be considered corrupt and ignored. The maximum number of labels allowed in the current DNS is 127 but the entire octet is reserved and would be required should DNS names ever be expanded to 255 labels. The following table gives some examples. The value of "labels" is at the top, the retrieved owner name on the left, and the table entry is the name to use in signature verification except that "bad" means the RR is corrupt.
labels= | 0 | 1 | 2 | 3 | 4 |
--------+-----+------+--------+----------+----------+
.| . | bad | bad | bad | bad |
d.| *. | d. | bad | bad | bad |
c.d.| *. | *.d. | c.d. | bad | bad |
b.c.d.| *. | *.d. | *.c.d. | b.c.d. | bad |
a.b.c.d.| *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
The "original TTL" field is included in the RDATA portion to avoid (1) authentication problems that caching servers would otherwise cause by decrementing the real TTL field and (2) security problems that unscrupulous servers could otherwise cause by manipulating the real TTL field. This original TTL is protected by the signature while the current TTL field is not.
NOTE: The "original TTL" must be restored into the covered RRs when the signature is verified. This implies that all RRs for a particular type, name, and class must have the same TTL to start with.
The SIG is valid until the "signature expiration" time which is an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds. (See also Section 4.4.) SIG RRs should not have a date signed significantly in the future. To prevent misordering of network requests to update a zone dynamically, monotonically increasing "time signed" dates may be necessary.
The "time signed" field is an unsigned number of seconds since the start of 1 January 1970, GMT, ignoring leap seconds.
A SIG RR with an expiration date before the time signed must be considered corrupt and ignored.
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 "signer's name" field is the domain name of the signer generating the SIG RR. This is the owner of the public KEY RR that can be used to verify the signature. It is frequently the zone which contained the RR(s) being authenticated. The signer's name may be compressed with standard DNS name compression when being transmitted over the network.
The structure of the "signature" field is described below.
4.1.1. Signature Data
Except for algorithm number 253 where it is null, the actual signature portion of 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 constructed as follows:
data = RDATA | RR(s)...
where "|" is concatenation, RDATA is all the RDATA fields in the SIG RR itself before and not including the signature, and RR(s) are 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.
For purposes of DNS security, the canonical form for an RR is the RR with domain names (1) fully expanded (no name compression via pointers), (2) all domain name letters set to lower case, and (3) the original TTL substituted for the current TTL.
For purposes of DNS security, the canonical order for RRs is to sort them in ascending order by name, considering labels as a left justified unsigned octet sequence in network (transmission) order where a missing octet sorts before a zero octet. (See also ordering discussion in Section 5.1.) Within any particular name they are similarly sorted by type and then RDATA as a left justified unsigned octet sequence. EXCEPT that the type SIG RR(s) covering any particular type appear immediately after the other RRs of that type. (This special consideration for SIG RR(s) in ordering really only applies to calculating the AXFR SIG RR as explained in section 4.1.3 below.) Thus if at name a.b there are two A RRs and one KEY RR, their order with SIGs for concatenating the "data" to be signed would be as follows:
a.b. A ....
a.b. A ....
a.b. SIG A ...
a.b. KEY ...
a.b. SIG KEY ...
SIGs covering type ANY should not be included in a zone.
4.1.2. MD5/RSA Algorithm Signature Calculation
For the MD5/RSA algorithm, the signature is as follows
hash = MD5 ( data )
signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
where MD5 is the message digest algorithm documented in RFC 1321, "|" is concatenation, "e" is the private key exponent of the signer, and "n" is the modulus of the signer's public key. 01, FF, and 00 are fixed octets of the corresponding hexadecimal value. "prefix" is the ASN.1 BER MD5 algorithm designator prefix specified in PKCS1, that is,
hex 3020300c06082a864886f70d020505000410 [NETSEC].
This prefix is included to make it easier to use RSAREF or similar packages. The FF octet is repeated the maximum number of times such that the value of the quantity being exponentiated is one octet shorter than the value of n.
(The above specifications are identical to the corresponding part of Public Key Cryptographic Standard #1 [PKCS1].)
The size of n, including most and least significant bits (which will be 1) SHALL be not less than 512 bits and not more than 2552 bits. n and e SHOULD be chosen such that the public exponent is small.
Leading zeros bytes are not permitted in the MD5/RSA algorithm signature.
A public exponent of 3 minimizes the effort needed to decode a signature. Use of 3 as the public exponent may be weak for confidentiality uses since, if the same data can be collected encrypted under three different keys with an exponent of 3 then, using the Chinese Remainder Theorem, the original plain text can be easily recovered. This weakness is not significant for DNS because we seek only authentication, not confidentiality.
4.1.3. Zone Transfer (AXFR) SIG
The above SIG mechanisms assure the authentication of all zone signed RRs of a particular name, class and type. However, 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 RRs are ordered and concatenated for hashing as described in Section 4.1.1. (See also ordering discussion in Section 5.1.)
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.
The AXFR SIG really belongs to the zone as a whole, not to the zone name. Although it should be correct for the zone name, the labels field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only retrieved as part of a zone transfer. After validation of the AXFR SIG, the zone MAY be considered valid without verification of the internal zone signed SIGs in the zone; however, any RRs authenticated by SIGs signed by entity keys or the like MUST still be validated. The AXFR SIG SHOULD be transmitted first in a zone transfer so the receiver can tell immediately that they may be able to avoid verifying other zone signed SIGs.
RRs which are authenticated by a dynamic update key and not by the zone key (see Section 3.2) are not included in the AXFR SIG. They may originate in the network and might not, in general, be migrated to the recommended off line zone signing procedure (see Section 7.2). Thus, such RRs are not directly signed by the zone, are not included in the AXFR SIG, and are protected against omission from zone transfers only to the extent that the server and communication can be trusted.
4.1.4. Transaction and Request SIGs
A response message from a security aware server may optionally contain a special SIG as the last item in the additional information section to authenticate the transaction.
This SIG has a "type covered" field of zero, which is not a valid RR type. It is calculated by using a "data" (see Section 4.1.2) of the entire preceding DNS reply message, including DNS header but not the IP header, concatenated with the entire DNS query message that produced this response, including the query's DNS header but not its IP header. That is
data = full response (less final transaction SIG) | full query
Verification of the transaction SIG (which is signed by the server host key, not the zone key) by the requesting resolver shows that the query and response were not tampered with in transit, that the response corresponds to the intended query, and that the response comes from the queried server.
A DNS request may be optionally signed by including one or more SIGs at the end of the query. Such SIGs are identified by having a "type covered" field of zero. They sign the preceding DNS request message including DNS header but not including the IP header or at the begining or any preceding request SIGs at the end. Such request SIGs are included in the "data" used to form any optional response transaction SIG.
WARNING: Request SIGs are unnecessary for currently defined queries and will cause almost all existing DNS servers to completely ignore a query. However, such SIGs may be needed to authenticate future DNS secure dynamic update or other requests.
4.2. SIG RRs in the Construction of Responses
Security aware DNS servers MUST, for every authoritative RR the query will return, attempt to send the available SIG RRs which authenticate the requested RR. The following rules apply to the inclusion of SIG RRs in responses:
1. when an RR set is placed in a response, its SIG RR has a higher priority for inclusion than other additional RRs that may need to be included. If space does not permit its inclusion, the response MUST be considered truncated except as provided in 2 below. 2. when a SIG RR is present in the zone for an additional information section RR, the response MUST NOT be considered truncated merely because space does not permit the inclusion of its SIG RR. 3. SIGs to authenticate non-authoritative data (glue records and NS RRs for subzones) are unnecessary and MUST NOT be sent. (Note that KEYs for subzones are controlling in a superzone so the superzone's signature on the KEY MUST be included (unless the KEY was additional information and the SIG did not fit).) 4. If a SIG covers any RR that would be in the answer section of the response, its automatic inclusion MUST be the answer section. If it covers an RR that would appear in the authority section, its automatic inclusion MUST be in the authority section. If it covers an RR that would appear in the additional information section it MUST appear in the additional information section. This is a change in the existing standard which contemplates only NS and SOA RRs in the authority section. 5. Optionally, DNS transactions may be authenticated by a SIG RR at the end of the response in the additional information section (Section 4.1.4). Such SIG RRs are signed by the DNS server originating the response. Although the signer field MUST be the name of the originating server host, the owner name, class, TTL, and original TTL, are meaningless. The class and TTL fields SHOULD be zero. To conserve space, the owner name SHOULD be root (a single zero octet). If transaction authentication is desired, that SIG RR must be considered higher priority for inclusion than any other RR in the response.
4.3. Processing Responses and SIG RRs
The following rules apply to the processing of SIG RRs included in a response:
1. a security aware resolver that receives a response from what it believes to be a security aware server via a secure communication with the AD bit (see Section 6.1) set, MAY choose to accept the RRs as received without verifying the zone SIG RRs. 2. in other cases, a security aware resolver SHOULD verify the SIG RRs for the RRs of interest. This may involve initiating additional queries for SIG or KEY RRs, especially in the case of getting a response from an insecure server. (As explained in 4.2 above, it will not be possible to secure CNAMEs being served up by non-secure resolvers.) NOTE: Implementers might expect the above SHOULD to be a MUST. However, local policy or the calling application may not require the security services. 3. If SIG RRs are received in response to a user query explicitly specifying the SIG type, no special processing is required.
If the message does not pass reasonable checks or the SIG does not check against the signed RRs, the SIG RR is invalid and should be ignored. If all of the SIG RR(s) purporting to authenticate a set of RRs are invalid, then the set of RR(s) is not authenticated.
If the SIG RR is the last RR in a response in the additional information section and has a type covered of zero, it is a transaction signature of the response and the query that produced the response. It MAY be optionally checked and the message rejected if the checks fail. But even if the checks succeed, such a transaction authentication SIG does NOT authenticate any RRs in the message. Only a proper SIG RR signed by the zone or a key tracing its authority to the zone or to static resolver configuration can authenticate RRs. If a resolver does not implement transaction and/or request SIGs, it MUST ignore them without error.
If all reasonable checks indicate that the SIG RR is valid then RRs verified by it should be considered authenticated.
4.4. Signature Expiration, TTLs, and Validity
Security aware servers must not consider SIG RRs to authenticate anything after their expiration time and not consider any RR to be authenticated after its signatures have expired. Within that constraint, servers should continue to follow DNS TTL aging. Thus authoritative servers should continue to follow the zone refresh and expire parameters and a non-authoritative server should count down the TTL and discard RRs when the TTL is zero. In addition, when RRs are transmitted in a query response, the TTL should be trimmed so that current time plus the TTL does not extend beyond the signature expiration time. Thus, in general, the TTL on an transmitted RR would be
min(sigExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
4.5. File Representation of SIG RRs
A SIG RR can be represented as a single logical line in a zone data file [RFC1033] but there are some special considerations as described below. (It does not make sense to include a transaction or request authenticating SIG RR in a file as they are a transient authentication that covers data including an ephemeral transaction number and so must be calculated in real time.)
There is no particular problem with the signer, covered type, and times. The time fields appears in the form YYYYMMDDHHMMSS where YYYY is the year, the first MM is the month number (01-12), DD is the day of the month (01-31), HH is the hour in 24 hours notation (00-23), the second MM is the minute (00-59), and SS is the second (00-59).
The original TTL and algorithm fields appear as unsigned integers.
If the original TTL, which applies to the type signed, is the same as the TTL of the SIG RR itself, it may be omitted. The date field which follows it is larger than the maximum possible TTL so there is no ambiguity.
The "labels" field does not appear in the file representation as it can be calculated from the owner name.
The key footprint appears as an unsigned decimal number.
However, the signature itself can be very long. It is the last data field and is represented in base 64 (see Appendix) and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full signature. These substrings can be split between lines using the standard parenthesis.