diff --git a/doc/draft/draft-ietf-dnsext-dns-threats-07.txt b/doc/draft/draft-ietf-dnsext-dns-threats-07.txt new file mode 100644 index 0000000000..15217dad2c --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dns-threats-07.txt @@ -0,0 +1,895 @@ + + +Network Working Group D. Atkins +draft-ietf-dnsext-dns-threats-07.txt IHTFP Consulting + R. Austein + ISC + April 2004 + + + Threat Analysis of the Domain Name System + + +Status of this document + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + + + The list of Internet-Draft Shadow Directories can be accessed at + + + Distribution of this document is unlimited. Please send comments to + the Namedroppers mailing list . + +Abstract + + Although the DNS Security Extensions (DNSSEC) have been under + development for most of the last decade, the IETF has never written + down the specific set of threats against which DNSSEC is designed to + protect. Among other drawbacks, this cart-before-the-horse situation + has made it difficult to determine whether DNSSEC meets its design + goals, since its design goals are not well specified. This note + attempts to document some of the known threats to the DNS, and, in + doing so, attempts to measure to what extent (if any) DNSSEC is a + useful tool in defending against these threats. + + + + + + +Atkins & Austein Expires 9 October 2004 [Page 1] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + +1. Introduction + + The earliest organized work on DNSSEC within the IETF was an open + design team meeting organized by members of the DNS working group in + November 1993 at the 28th IETF meeting in Houston. The broad + outlines of DNSSEC as we know it today are already clear in Jim + Galvin's summary of the results of that meeting [Galvin93]: + + - While some participants in the meeting were interested in + protecting against disclosure of DNS data to unauthorized parties, + the design team made an explicit decision that "DNS data is + `public'", and ruled all threats of data disclosure explicitly out + of scope for DNSSEC. + + - While some participants in the meeting were interested in + authentication of DNS clients and servers as a basis for access + control, this work was also ruled out of scope for DNSSEC per se. + + - Backwards compatibility and co-existence with "insecure DNS" was + listed as an explicit requirement. + + - The resulting list of desired security services was + 1) data integrity, and + 2) data origin authentication. + + - The design team noted that a digital signature mechanism would + support the desired services. + + While a number of detail decisions were yet to be made (and in some + cases remade after implementation experience) over the subsequent + decade, the basic model and design goals have remained fixed. + + Nowhere, however, does any of the DNSSEC work attempt to specify in + any detail the sorts of attacks against which DNSSEC is intended to + protect, or the reasons behind the list of desired security services + that came out of the Houston meeting. For that, we have to go back + to a paper originally written by Steve Bellovin in 1990 but not + published until 1995, for reasons that Bellovin explained in the + paper's epilogue [Bellovin95]. + + While it may seem a bit strange to publish the threat analysis a + decade after starting work on the protocol designed to defend against + it, that is nevertheless what this note attempts to do. Better late + than never. + + This note assumes that the reader is familiar with both the DNS and + with DNSSEC, and does not attempt to provide a tutorial on either. + The DNS documents most relevant to the subject of this note are: + + + +Atkins & Austein Expires 9 October 2004 [Page 2] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], + [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535]. + + For purposes of discussion, this note uses the term "DNSSEC" to refer + to the core hierarchical public key and signature mechanism specified + in the DNSSEC documents, and refers to TKEY and TSIG as separate + mechanisms, even though channel security mechanisms such as TKEY and + TSIG are also part of the larger problem of "securing DNS" and thus + are often considered part of the overall set of "DNS security + extensions". This is an arbitrary distinction that in part reflects + the way in which the protocol has evolved (introduction of a + putatively simpler channel security model for certain operations such + as zone transfers and dynamic update requests), and perhaps should be + changed in a future revision of this note. + +2. Known Threats + + There are several distinct classes of threats to the DNS, most of + which are DNS-related instances of more general problems, but a few + of which are specific to peculiarities of the DNS protocol. + +2.1. Packet Interception + + Some of the simplest threats against DNS are various forms of packet + interception: monkey-in-the-middle attacks, eavesdropping on requests + combined with spoofed responses that beat the real response back to + the resolver, and so forth. In any of these scenarios, the attacker + can simply tell either party (usually the resolver) whatever it wants + that party to believe. While packet interception attacks are far + from unique to DNS, DNS's usual behavior of sending an entire query + or response in a single unsigned, unencrypted UDP packet makes these + attacks particularly easy for any bad guy with the ability to + intercept packets on a shared or transit network. + + To further complicate things, the DNS query the attacker intercepts + may just be a means to an end for the attacker: the attacker might + even choose to return the correct result in the answer section of a + reply message while using other parts of the message to set the stage + for something more complicated, for example, a name-based attack (see + below). + + While it certainly would be possible to sign DNS messages using a + channel security mechanism such as TSIG or IPsec, or even to encrypt + them using IPsec, this would not be a very good solution. First, + this approach would impose a fairly high processing cost per DNS + message, as well as a very high cost associated with establishing and + maintaining bilateral trust relationships between all the parties + that might be involved in resolving any particular query. For + + + +Atkins & Austein Expires 9 October 2004 [Page 3] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + heavily used name servers (such as the servers for the root zone), + this cost would almost certainly be prohibitively high. Even more + important, however, is that the underlying trust model in such a + design would be wrong, since at best it would only provide a hop-by- + hop integrity check on DNS messages and would not provide any sort of + end-to-end integrity check between the producer of DNS data (the zone + administrator) and the consumer of DNS data (the application that + triggered the query). + + By contrast, DNSSEC (when used properly) does provide an end-to-end + data integrity check, and is thus a much better solution for this + class of problems during basic DNS lookup operations. + + TSIG does have its place in corners of the DNS protocol where there's + a specific trust relationship between a particular client and a + particular server, such as zone transfer, dynamic update, or a + resolver (stub or otherwise) that is not going to check all the + DNSSEC signatures itself. + + Note that DNSSEC does not provide any protection against modification + of the DNS message header, so any properly paranoid resolver must: + + - Perform all of the DNSSEC signature checking on its own, + + - Use TSIG (or some equivalent mechanism) to ensure the integrity of + its communication with whatever name servers it chooses to trust, + or + + - Resign itself to the possibility of being attacked via packet + interception (and via other techniques discussed below). + +2.2. ID Guessing and Query Prediction + + Since DNS is for the most part used over UDP/IP, it is relatively + easy for an attacker to generate packets which will match the + transport protocol parameters. The ID field in the DNS header is + only a 16-bit field and the server UDP port associated with DNS is a + well-known value, so there are only 2**32 possible combinations of ID + and client UDP port for a given client and server. This is not a + particularly large range, and is not sufficient to protect against a + brute force search; furthermore, in practice both the client UDP port + and the ID can often be predicted from previous traffic, and it is + not uncommon for the client port to be a known fixed value as well + (due to firewalls or other restrictions), thus frequently reducing + the search space to a range smaller than 2**16. + + By itself, ID guessing is not enough to allow an attacker to inject + bogus data, but combined with knowledge (or guesses) about QNAMEs and + + + +Atkins & Austein Expires 9 October 2004 [Page 4] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + QTYPEs for which a resolver might be querying, this leaves the + resolver only weakly defended against injection of bogus responses. + + Since this attack relies on predicting a resolver's behavior, it's + most likely to be successful when the victim is in a known state, + whether because the victim rebooted recently, or because the victim's + behavior has been influenced by some other action by the attacker, or + because the victim is responding (in a predictable way) to some third + party action known to the attacker. + + This attack is both more and less difficult for the attacker than the + simple interception attack described above: more difficult, because + the attack only works when the attacker guesses correctly; less + difficult, because the attacker doesn't need to be on a transit or + shared network. + + In most other respects, this attack is similar to a packet + interception attack. A resolver that checks DNSSEC signatures will + be able to detect the forged response; resolvers that do not + themselves perform DNSSEC signature checking should use TSIG or some + equivalent mechanism to ensure the integrity of their communication + with a recursing name server that does perform DNSSEC signature + checking. + +2.3. Name Chaining + + Perhaps the most interesting class of DNS-specific threats are the + name chaining attacks. These are a subset of a larger class of name- + based attacks, sometimes called "cache poisoning" attacks. Most + name-based attacks can be at least partially mitigated by the long- + standing defense of checking RRs in response messages for relevance + to the original query, but such defenses do not catch name chaining + attacks. There are several variations on the basic attack, but what + they all have in common is that they all involve DNS RRs whose RDATA + portion (right hand side) includes a DNS name (or, in a few cases, + something that is not a DNS name but which directly maps to a DNS + name). Any such RR is, at least in principle, a hook that lets an + attacker feed bad data into a victim's cache, thus potentially + subverting subsequent decisions based on DNS names. + + The worst examples in this class of RRs are CNAME, NS, and DNAME RRs, + because they can redirect a victim's query to a location of the + attacker's choosing. RRs like MX and SRV are somewhat less + dangerous, but in principle they can also be used to trigger further + lookups at a location of the attacker's choosing. Address RR types + such as A or AAAA don't have DNS names in their RDATA, but since the + IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of + IPv4 and IPv6 addresses, these record types can also be used in a + + + +Atkins & Austein Expires 9 October 2004 [Page 5] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + name chaining attack. + + The general form of a name chaining attack is something like this: + + - Victim issues a query, perhaps at the instigation of the attacker + or some third party; in some cases the query itself may be + unrelated to the name under attack (that is, the attacker is just + using this query as a means to inject false information about some + other name). + + - Attacker injects response, whether via packet interception, query + guessing, or by being a legitimate name server that's involved at + some point in the process of answering the query that the victim + issued. + + - Attacker's response includes one or more RRs with DNS names in + their RDATA; depending on which particular form this attack takes, + the object may be to inject false data associated with those names + into the victim's cache via the Additional section of this + response, or may be to redirect the next stage of the query to a + server of the attacker's choosing (in order to inject more complex + lies into the victim's cache than will fit easily into a single + response, or in order to place the lies in the Authority or Answer + section of a response where they will have a better chance of + sneaking past a resolver's defenses). + + Any attacker who can insert resource records into a victim's cache + can almost certainly do some kind of damage, so there are cache + poisoning attacks which are not name chaining attacks in the sense + discussed here. However, in the case of name chaining attacks, the + cause and effect relationship between the initial attack and the + eventual result may be significantly more complex than in the other + forms of cache poisoning, so name chaining attacks merit special + attention. + + The common thread in all of the name chaining attacks is that + response messages allow the attacker to introduce arbitrary DNS names + of the attacker's choosing and provide further information that the + attacker claims is associated with those names; unless the victim has + better knowledge of the data associated with those names, the victim + is going to have a hard time defending against this class of attacks. + + This class of attack is particularly insidious given that it's quite + easy for an attacker to provoke a victim into querying for a + particular name of the attacker's choosing, for example, by embedding + a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail + to the victim. If the victim's mail reading program attempts to + follow such a link, the result will be a DNS query for a name chosen + + + +Atkins & Austein Expires 9 October 2004 [Page 6] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + by the attacker. + + DNSSEC should provide a good defense against most (all?) variations + on this class of attack. By checking signatures, a resolver can + determine whether the data associated with a name really was inserted + by the delegated authority for that portion of the DNS name space + (more precisely, a resolver can determine whether the entity that + injected the data had access to an allegedly secret key whose + corresponding public key appears at an expected location in the DNS + name space with an expected chain of parental signatures that start + with a public key of which the resolver has prior knowledge). + + DNSSEC signatures do not cover glue records, so there's still a + possibility of a name chaining attack involving glue, but with DNSSEC + it is possible to detect the attack by temporarily accepting the glue + in order to fetch the signed authoritative version of the same data, + then checking the signatures on the authoritative version. + +2.4. Betrayal By Trusted Server + + Another variation on the packet interception attack is the trusted + server that turns out not to be so trustworthy, whether by accident + or by intent. Many client machines are only configured with stub + resolvers, and use trusted servers to perform all of their DNS + queries on their behalf. In many cases the trusted server is + furnished by the user's ISP and advertised to the client via DHCP or + PPP options. Besides accidental betrayal of this trust relationship + (via server bugs, successful server break-ins, etc), the server + itself may be configured to give back answers that are not what the + user would expect (whether in an honest attempt to help the user or + to further some other goal such as furthering a business partnership + between the ISP and some third party). + + This problem is particularly acute for frequent travelers who carry + their own equipment and expect it to work in much the same way no + matter which network it's plugged into at any given moment (and no + matter what brand of middle boxes a particular hotel chain might have + installed when adding network drops in every guest room...). + + While the obvious solution to this problem would be for the client to + choose a more trustworthy server, in practice this may not be an + option for the client. In many network environments a client machine + has only a limited set of recursive name servers from which to + choose, and none of them may be particularly trustworthy. In extreme + cases, port filtering or other forms of packet interception may + prevent the client host from being able to run an iterative resolver + even if the owner of the client machine is willing and able to do so. + Thus, while the initial source of this problem is not a DNS protocol + + + +Atkins & Austein Expires 9 October 2004 [Page 7] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + attack per se, this sort of betrayal is a threat to DNS clients, and + simply switching to a different recursive name server is not an + adequate defense. + + Viewed strictly from the DNS protocol standpoint, the only difference + between this sort of betrayal and a packet interception attack is + that in this case the client has voluntarily sent its request to the + attacker. The defense against this is the same as with a packet + interception attack: the resolver must either check DNSSEC signatures + itself or use TSIG (or equivalent) to authenticate the server that it + has chosen to trust. Note that use of TSIG does not by itself + guarantee that a name server is at all trustworthy: all TSIG can do + is help a resolver protect its communication with a name server that + it has already decided to trust for other reasons. Protecting a + resolver's communication with a server that's giving out bogus + answers is not particularly useful. + + Also note that if the stub resolver does not trust the name server + that is doing work on its behalf and wants to check the DNSSEC + signatures itself, the resolver really does need to have independent + knowledge of the DNSSEC public key(s) it needs in order to perform + the check (usually the public key for the root zone, but in some + cases knowledge of additional keys may also be appropriate). + + It is difficult to escape the conclusion that a properly paranoid + resolver must always perform its own signature checking, and that + this rule even applies to stub resolvers. + +2.5. Denial of Service + + As with any network service (or, indeed, almost any service of any + kind in any domain of discourse), DNS is vulnerable to denial of + service attacks. DNSSEC does not help this, and may in fact make the + problem worse for resolvers that check signatures, since checking + signatures both increases the processing cost per DNS message and in + some cases can also increase the number of messages needed to answer + a query. TSIG (and similar mechanisms) have equivalent problems. + + DNS servers are also at risk of being used as denial of service + amplifiers, since DNS response packets tend to be significantly + longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help + here either. + +2.6. Authenticated Denial of Domain Names + + Much discussion has taken place over the question of authenticated + denial of domain names. The particular question is whether there is + a requirement for authenticating the non-existence of a name. The + + + +Atkins & Austein Expires 9 October 2004 [Page 8] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + issue is whether the resolver should be able to detect when an + attacker removes RRs from a response. + + General paranoia aside, the existence of RR types whose absence + causes an action other than immediate failure (such as missing MX and + SRV RRs, which fail over to A RRs) constitutes a real threat. + Arguably, in some cases, even the immediate failure of a missing RR + might be considered a problem. The question remains: how serious is + this threat? Clearly the threat does exist; general paranoia says + that some day it'll be on the front page of some major newspaper, + even if we cannot conceive of a plausible scenario involving this + attack today. This implies that some mitigation of this risk is + required. + + Note that it's necessary to prove the non-existence of applicable + wildcard RRs as part of the authenticated denial mechanism, and that, + in a zone that is more than one label deep, such a proof may require + proving the non-existence of multiple discrete sets of wildcard RRs. + + DNSSEC does include mechanisms which make it possible to determine + which authoritative names exist in a zone, and which authoritative + resource record types exist at those names. The DNSSEC protections + do not cover non-authoritative data such as glue records. + +2.7. Wildcards + + Much discussion has taken place over whether and how to provide data + integrity and data origin authentication for "wildcard" DNS names. + Conceptually, RRs with wildcard names are patterns for synthesizing + RRs on the fly according to the matching rules described in section + 4.3.2 of RFC 1034. While the rules that control the behavior of + wildcard names have a few quirks that can make them a trap for the + unwary zone administrator, it's clear that a number of sites make + heavy use of wildcard RRs, particularly wildcard MX RRs. + + In order to provide the desired services for wildcard RRs, we need to + do two things: + + - We need a way to attest to the existence of the wildcard RR itself + (that is, we need to show that the synthesis rule exists), and + + - We need a way to attest to the non-existence of any RRs which, if + they existed, would make the wildcard RR irrelevant according to + the synthesis rules that govern the way in which wildcard RRs are + used (that is, we need to show that the synthesis rule is + applicable). + + Note that this makes the wildcard mechanisms dependent upon the + + + +Atkins & Austein Expires 9 October 2004 [Page 9] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + authenticated denial mechanism described in the previous section. + + DNSSEC includes mechanisms along the lines described above, which + make it possible for a resolver to verify that a name server applied + the wildcard expansion rules correctly when generating an answer. + +3. Weaknesses of DNSSEC + + DNSSEC has some problems of its own: + + - DNSSEC is complex to implement, and includes some nasty edge cases + at the zone cuts that require very careful coding. Testbed + experience to date suggests that trivial zone configuration errors + or expired keys can cause serious problems for a DNSSEC-aware + resolver, and that the current protocol's error reporting + capabilities may leave something to be desired. + + - DNSSEC significantly increases the size of DNS response packets; + among other issues, this makes DNSSEC-aware DNS servers even more + effective as denial of service amplifiers. + + - DNSSEC answer validation increases the resolver's work load, since + a DNSSEC-aware resolver will need to perform signature validation + and in some cases will also need to issue further queries. This + increased workload will also increase the time it takes to get an + answer back to the original DNS client, which is likely to trigger + both timeouts and re-queries in some cases. (Arguably, many + current DNS clients are already too impatient even before taking + the further delays that DNSSEC will impose into account, but that's + a separate topic for another document....) + + - Like DNS itself, DNSSEC's trust model is almost totally + hierarchical. While DNSSEC does allow resolvers to have special + additional knowledge of public keys beyond those for the root, in + the general case the root key is the one that matters. Thus any + compromise in any of the zones between the root and a particular + target name can damage DNSSEC's ability to protect the integrity of + data owned by that target name. This is not a change, since + insecure DNS has the same model. + + - Key rollover at the root is really hard. Work to date has not even + come close to adequately specifying how the root key rolls over, or + even how it's configured in the first place. + + - DNSSEC creates a requirement of loose time synchronization between + the validating resolver and the entity creating the DNSSEC + signatures. Prior to DNSSEC, all time-related actions in DNS could + be performed by a machine that only knew about "elapsed" or + + + +Atkins & Austein Expires 9 October 2004 [Page 10] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + "relative" time. Because the validity period of a DNSSEC signature + is based on "absolute" time, a validating resolver must have the + same concept of absolute time as the zone signer in order to + determine whether the signature is within its validity period or + has expired. An attacker that can change a resolver's opinion of + the current absolute time can fool the resolver using expired + signatures. An attacker that can change the zone signer's opinion + of the current absolute time can fool the zone signer into + generating signatures whose validity period does not match what the + signer intended. + + - The possible existence of wildcard RRs in a zone complicates the + authenticated denial mechanism considerably. For most of the + decade that DNSSEC has been under development these issues were + poorly understood. At various times there have been questions as + to whether the authenticated denial mechanism is completely + airtight and whether it would be worthwhile to optimize the + authenticated denial mechanism for the common case in which + wildcards are not present in a zone, but the main problem is just + the inherent complexity of the wildcard mechanism itself. This + complexity probably makes the code for generating and checking + authenticated denial attestations somewhat fragile, but since the + alternative of giving up wildcards entirely is not practical due to + widespread use, we are going to have to live with wildcards, and + the question just becomes one of whether or not the proposed + optimizations would make DNSSEC's mechanisms more or less fragile. + + - Even with DNSSEC, the class of attacks discussed in section 2.4 is + not easy to defeat. In order for DNSSEC to be effective in this + case, it must be possible to configure the resolver to expect + certain categories of DNS records to be signed, which may require + manual configuration of the resolver, especially during the initial + DNSSEC rollout period when the resolver cannot reasonably expect + the root and TLD zones to be signed. + + +4. Topics for Future Work + + This section lists a few subjects not covered above which probably + need additional study, additional mechanisms, or both. + +4.1. Interactions With Other Protocols + + The above discussion has concentrated exclusively on attacks within + the boundaries of the DNS protocol itself, since those are the + problems against (some of) which DNSSEC was intended to protect. + There are, however, other potential problems at the boundaries where + DNS interacts with other protocols. + + + +Atkins & Austein Expires 9 October 2004 [Page 11] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + +4.2. Securing DNS Dynamic Update + + DNS dynamic update opens a number of potential problems when combined + with DNSSEC. Dynamic update of a non-secure zone can use TSIG to + authenticate the updating client to the server. While TSIG does not + scale very well (it requires manual configuration of shared keys + between the DNS name server and each TSIG client), it works well in a + limited or closed environment such as a DHCP server updating a local + DNS name server. + + Major issues arise when trying to use dynamic update on a secure + zone. TSIG can similarly be used in a limited fashion to + authenticate the client to the server, but TSIG only protects DNS + transactions, not the actual data, and the TSIG is not inserted into + the DNS zone, so resolvers cannot use the TSIG as a way of verifying + the changes to the zone. This means that either: + + a) The updating client must have access to a zone-signing key in + order to sign the update before sending it to the server, or + + b) The DNS name server must have access to an online zone-signing key + in order to sign the update. + + In either case, a zone-signing key must be available to create signed + RRsets to place in the updated zone. The fact that this key must be + online (or at least available) is a potential security risk. + + Dynamic update also requires an update to the SERIAL field of the + zone's SOA RR. In theory, this could also be handled via either of + the above options, but in practice (a) would almost certainly be + extremely fragile, so (b) is the only workable mechanism. + + There are other threats in terms of describing the policy of who can + make what changes to which RRsets in the zone. The current access + control scheme in Secure Dynamic Update is fairly limited. There is + no way to give fine-grained access to updating DNS zone information + to multiple entities, each of whom may require different kinds of + access. For example, Alice may need to be able to add new nodes to + the zone or change existing nodes, but not remove them; Bob may need + to be able to remove zones but not add them; Carol may need to be + able to add, remove, or modify nodes, but only A records. + + Scaling properties of the key management problem here are a + particular concern that needs more study. + + + + + + + +Atkins & Austein Expires 9 October 2004 [Page 12] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + +4.3. Securing DNS Zone Replication + + As discussed in previous sections, DNSSEC per se attempts to provide + data integrity and data origin authentication services on top of the + normal DNS query protocol. Using the terminology discussed in + [RFC3552], DNSSEC provides "object security" for the normal DNS query + protocol. For purposes of replicating entire DNS zones, however, + DNSSEC does not provide object security, because zones include + unsigned NS RRs and glue at delegation points. Use of TSIG to + protect zone transfer (AXFR or IXFR) operations provides "channel + security", but still does not provide object security for complete + zones, so the trust relationships involved in zone transfer are still + very much a hop-by-hop matter of name server operators trusting other + name server operators, rather than an end-to-end matter of name + server operators trusting zone administrators. + + Zone object security was not an explicit design goal of DNSSEC, so + failure to provide this service should not be a surprise. + Nevertheless, there are some zone replication scenarios for which + this would be a very useful additional service, so this seems like a + useful area for future work. In theory it should not be difficult to + zone object security as a backwards compatible enhancement to the + existing DNSSEC model, but the DNSEXT WG has not yet discussed either + the desirability of or the requirements for such an enhancement. + +5. Conclusion + + Based on the above analysis, the DNSSEC extensions do appear to solve + a set of problems that do need to be solved, and are worth deploying. + +Security Considerations + + This entire document is about security considerations of the DNS. + The authors believe that deploying DNSSEC will help to address some, + but not all, of the known threats to the DNS. + +IANA Considerations + + None. + +Acknowledgments + + This note is based both previous published works by others and on a + number of discussions both public and private over a period of many + years, but particular thanks go to Jaap Akkerhuis, Steve Bellovin, + Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ + Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten + Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other + + + +Atkins & Austein Expires 9 October 2004 [Page 13] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose + names and contributions the authors have forgotten, none of whom are + responsible for what the authors did with their ideas. + + As with any work of this nature, the authors of this note acknowledge + that we are standing on the toes of those who have gone before us. + Readers interested in this subject may also wish to read + [Bellovin95], [Schuba93], and [Vixie95]. + +Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", RFC 1035, November 1987. + + [RFC1123] Braden, R., Editor, "Requirements for Internet Hosts - + Application and Support", RFC 1123, October 1989. + + [RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS + Specification" RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)" + RFC 2308, March 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)" RFC 2845, May 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)" + RFC 2930, September 2000. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update" RFC 3007, November 2000. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + +Informative References + + [RFC3552] Rescorla, E., Korver, B., and the Internet Architecture + Board, "Guidelines for Writing RFC Text on Security + Considerations", RFC 3552, July 2003. + + + + +Atkins & Austein Expires 9 October 2004 [Page 14] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + [Bellovin95] Bellovin, S., "Using the Domain Name System for System + Break-Ins", Proceedings of the Fifth Usenix Unix Security + Symposium, June 1995. + + [Galvin93] Design team meeting summary message posted to dns- + security@tis.com mailing list by Jim Galvin on 19 November 1993. + + [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name + System Protocol", Master's thesis, Purdue University Department + of Computer Sciences, August 1993. + + [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of + the Fifth Usenix Unix Security Symposium, June 1995. + +Authors' addresses: + + Derek Atkins + IHTFP Consulting, Inc. + 6 Farragut Ave + Somerville, MA 02144 + USA + + Email: derek@ihtfp.com + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + Email: sra@isc.org +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + + + +Atkins & Austein Expires 9 October 2004 [Page 15] + +draft-ietf-dnsext-dns-threats-07.txt April 2004 + + + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + +Atkins & Austein Expires 9 October 2004 [Page 16] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt new file mode 100644 index 0000000000..5ac9cba56e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-10.txt @@ -0,0 +1,1513 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: November 15, 2004 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + May 17, 2004 + + + DNS Security Introduction and Requirements + draft-ietf-dnsext-dnssec-intro-10 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 15, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + The Domain Name System Security Extensions (DNSSEC) add data origin + authentication and data integrity to the Domain Name System. This + document introduces these extensions, and describes their + capabilities and limitations. This document also discusses the + services that the DNS security extensions do and do not provide. + + + +Arends, et al. Expires November 15, 2004 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + Last, this document describes the interrelationships between the + group of documents that collectively describe DNSSEC. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4 + 3. Services Provided by DNS Security . . . . . . . . . . . . . . 8 + 3.1 Data Origin Authentication and Data Integrity . . . . . . 8 + 3.2 Authenticating Name and Type Non-Existence . . . . . . . . 9 + 4. Services Not Provided by DNS Security . . . . . . . . . . . . 11 + 5. Scope of the DNSSEC Document Set and Last Hop Issues . . . . . 12 + 6. Resolver Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 15 + 8. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 8.1 TTL values vs. RRSIG validity period . . . . . . . . . . . 16 + 8.2 New Temporal Dependency Issues for Zones . . . . . . . . . 16 + 9. Name Server Considerations . . . . . . . . . . . . . . . . . . 17 + 10. DNS Security Document Family . . . . . . . . . . . . . . . . 18 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 20 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 + 14.2 Informative References . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 + Intellectual Property and Copyright Statements . . . . . . . . 26 + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 2] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +1. Introduction + + This document introduces the Domain Name System Security Extensions + (DNSSEC). This document and its two companion documents + ([I-D.ietf-dnsext-dnssec-records] and + [I-D.ietf-dnsext-dnssec-protocol]) update, clarify, and refine the + security extensions defined in RFC 2535 [RFC2535] and its + predecessors. These security extensions consist of a set of new + resource record types and modifications to the existing DNS protocol + [RFC1035]. The new records and protocol modifications are not fully + described in this document, but are described in a family of + documents outlined in Section 10. Section 3 and Section 4 describe + the capabilities and limitations of the security extensions in + greater detail. Section 5 discusses the scope of the document set. + Section 6, Section 7, Section 8, and Section 9 discuss the effect + that these security extensions will have on resolvers, stub + resolvers, zones and name servers. + + This document and its two companions update and obsolete RFCs 2535 + [RFC2535], 3008 [RFC3008], 3090 [RFC3090], 3445 [RFC3445], 3655 + [RFC3655], 3658 [RFC3658], 3755 [RFC3755], and the Work in Progress + [I-D.ietf-dnsext-nsec-rdata]. This document set also updates, but + does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 + [RFC2136], 2181 [RFC2181], 2308 [RFC2308], 3597 [RFC3597], and parts + of 3226 [RFC3226] (dealing with DNSSEC). + + The DNS security extensions provide origin authentication and + integrity protection for DNS data, as well as a means of public key + distribution. These extensions do not provide confidentiality. + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 3] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +2. Definitions of Important DNSSEC Terms + + This section defines a number of terms used in this document set. + Since this is intended to be useful as a reference while reading the + rest of the document set, first-time readers may wish to skim this + section quickly, read the rest of this document, then come back to + this section. + + Authentication Chain: An alternating sequence of DNSKEY RRsets and DS + RRsets forms a chain of signed data, with each link in the chain + vouching for the next. A DNSKEY RR is used to verify the + signature covering a DS RR and allows the DS RR to be + authenticated. The DS RR contains a hash of another DNSKEY RR and + this new DNSKEY RR is authenticated by matching the hash in the DS + RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset + and, in turn, some DNSKEY RR in this set may be used to + authenticate another DS RR and so forth until the chain finally + ends with a DNSKEY RR whose corresponding private key signs the + desired DNS data. For example, the root DNSKEY RRset can be used + to authenticate the DS RRset for "example." The "example." DS + RRset contains a hash that matches some "example." DNSKEY, and + this DNSKEY's corresponding private key signs the "example." + DNSKEY RRset. Private key counterparts of the "example." DNSKEY + RRset sign data records such as "www.example." as well as DS RRs + for delegations such as "subzone.example." + + Authentication Key: A public key that a security-aware resolver has + verified and can therefore use to authenticate data. A + security-aware resolver can obtain authentication keys in three + ways. First, the resolver is generally configured to know about + at least one public key; this configured data is usually either + the public key itself or a hash of the public key as found in the + DS RR (see "trust anchor"). Second, the resolver may use an + authenticated public key to verify a DS RR and its associated + DNSKEY RR. Third, the resolver may be able to determine that a + new public key has been signed by the private key corresponding to + another public key which the resolver has verified. Note that the + resolver must always be guided by local policy when deciding + whether to authenticate a new public key, even if the local policy + is simply to authenticate any new public key for which the + resolver is able verify the signature. + + Delegation Point: Term used to describe the name at the parental side + of a zone cut. That is, the delegation point for "foo.example" + would be the foo.example node in the "example" zone (as opposed to + the zone apex of the "foo.example" zone). + + + + + +Arends, et al. Expires November 15, 2004 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + Island of Security: Term used to describe a signed, delegated zone + that does not have an authentication chain from its delegating + parent. That is, there is no DS RR containing a hash of a DNSKEY + RR for the island in its delegating parent zone (see + [I-D.ietf-dnsext-dnssec-records]). An island of security is served + by security-aware name servers and may provide authentication + chains to any delegated child zones. Responses from an island of + security or its descendents can only be authenticated if its + authentication keys can be authenticated by some trusted means out + of band from the DNS protocol. + + Key Signing Key: An authentication key that corresponds to a private + key used to sign one or more other authentication keys for a given + zone. Typically, the private key corresponding to a key signing + key will sign a zone signing key, which in turn has a + corresponding private key which will sign other zone data. Local + policy may require the zone signing key to be changed frequently, + while the key signing key may have a longer validity period in + order to provide a more stable secure entry point into the zone. + Designating an authentication key as a key signing key is purely + an operational issue: DNSSEC validation does not distinguish + between key signing keys and other DNSSEC authentication keys, and + it is possible to use a single key as both a key signing key and a + zone signing key. Key signing keys are discussed in more detail + in [RFC3757]. Also see: zone signing key. + + Non-Validating Security-Aware Stub Resolver: A security-aware stub + resolver which trusts one or more security-aware recursive name + servers to perform most of the tasks discussed in this document + set on its behalf. In particular, a non-validating security-aware + stub resolver is an entity which sends DNS queries, receives DNS + responses, and is capable of establishing an appropriately secured + channel to a security-aware recursive name server which will + provide these services on behalf of the security-aware stub + resolver. See also: security-aware stub resolver, validating + security-aware stub resolver. + + Non-Validating Stub Resolver: A less tedious term for a + non-validating security-aware stub resolver. + + Security-Aware Name Server: An entity acting in the role of a name + server (defined in section 2.4 of [RFC1034]) that understands the + DNS security extensions defined in this document set. In + particular, a security-aware name server is an entity which + receives DNS queries, sends DNS responses, supports the EDNS0 + [RFC2671] message size extension and the DO bit [RFC3225], and + supports the RR types and message header bits defined in this + document set. + + + +Arends, et al. Expires November 15, 2004 [Page 5] + + + Security-Aware Recursive Name Server: An entity which acts in both + the security-aware name server and security-aware resolver roles. + A more cumbersome equivalent phrase would be "a security-aware + name server which offers recursive service". + + Security-Aware Resolver: An entity acting in the role of a resolver + (defined in section 2.4 of [RFC1034]) which understands the DNS + security extensions defined in this document set. In particular, + a security-aware resolver is an entity which sends DNS queries, + receives DNS responses, supports the EDNS0 [RFC2671] message size + extension and the DO bit [RFC3225], and is capable of using the RR + types and message header bits defined in this document set to + provide DNSSEC services. + + Security-Aware Stub Resolver: An entity acting in the role of a stub + resolver (defined in section 5.3.1 of [RFC1034]) which has enough + of an understanding the DNS security extensions defined in this + document set to provide additional services not available from a + security-oblivious stub resolver. Security-aware stub resolvers + may be either "validating" or "non-validating" depending on + whether the stub resolver attempts to verify DNSSEC signatures on + its own or trusts a friendly security-aware name server to do so. + See also: validating stub resolver, non-validating stub resolver. + + Security-Oblivious : An that is not + "security-aware". + + Signed Zone: A zone whose RRsets are signed and which contains + properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS + records. + + Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A + validating security-aware resolver uses this public key or hash as + a starting point for building the authentication chain to a signed + DNS response. In general, a validating resolver will need to + obtain the initial values of its trust anchors via some secure or + trusted means outside the DNS protocol. Presence of a trust + anchor also implies that the resolver should expect the zone to + which the trust anchor points to be signed + + Unsigned Zone: A zone that is not signed. + + Validating Security-Aware Stub Resolver: A security-aware resolver + that sends queries in recursive mode but which performs signature + validation on its own rather than just blindly trusting an + upstream security-aware recursive name server. See also: + security-aware stub resolver, non-validating security-aware stub + resolver. + + + + + +Arends, et al. Expires November 15, 2004 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + Validating Stub Resolver: A less tedious term for a validating + security-aware stub resolver. + + Zone Signing Key: An authentication key that corresponds to a private + key used to sign a zone. Typically a zone signing key will be + part of the same DNSKEY RRset as the key signing key whose + corresponding private key signs this DNSKEY RRset, but the zone + signing key is used for a slightly different purpose, and may + differ from the key signing key in other ways, such as validity + lifetime. Designating an authentication key as a zone signing key + is purely an operational issue: DNSSEC validation does not + distinguish between zone signing keys and other DNSSEC + authentication keys, and it is possible to use a single key as + both a key signing key and a zone signing key. See also: key + signing key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 7] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +3. Services Provided by DNS Security + + The Domain Name System (DNS) security extensions provide origin + authentication and integrity assurance services for DNS data, + including mechanisms for authenticated denial of existence of DNS + data. These mechanisms are described below. + + These mechanisms require changes to the DNS protocol. DNSSEC adds + four new resource record types (RRSIG, DNSKEY, DS and NSEC) and two + new message header bits (CD and AD). In order to support the larger + DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also + requires EDNS0 support [RFC2671]. Finally, DNSSEC requires support + for the DO bit [RFC3225], so that a security-aware resolver can + indicate in its queries that it wishes to receive DNSSEC RRs in + response messages. + + These services protect against most of the threats to the Domain Name + System described in [I-D.ietf-dnsext-dns-threats]. + +3.1 Data Origin Authentication and Data Integrity + + DNSSEC provides authentication by associating cryptographically + generated digital signatures with DNS RRsets. These digital + signatures are stored in a new resource record, the RRSIG record. + Typically, there will be a single private key that signs a zone's + data, but multiple keys are possible: for example, there may be keys + for each of several different digital signature algorithms. If a + security-aware resolver reliably learns a zone's public key, it can + authenticate that zone's signed data. An important DNSSEC concept is + that the key that signs a zone's data is associated with the zone + itself and not with the zone's authoritative name servers (public + keys for DNS transaction authentication mechanisms may also appear in + zones, as described in [RFC2931], but DNSSEC itself is concerned with + object security of DNS data, not channel security of DNS + transactions). + + A security-aware resolver can learn a zone's public key either by + having a trust anchor configured into the resolver or by normal DNS + resolution. To allow the latter, public keys are stored in a new + type of resource record, the DNSKEY RR. Note that the private keys + used to sign zone data must be kept secure, and should be stored + offline when practical to do so. To discover a public key reliably + via DNS resolution, the target key itself needs to be signed by + either a configured authentication key or another key that has been + authenticated previously. Security-aware resolvers authenticate zone + information by forming an authentication chain from a newly learned + public key back to a previously known authentication public key, + which in turn either has been configured into the resolver or must + + + +Arends, et al. Expires November 15, 2004 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + have been learned and verified previously. Therefore, the resolver + must be configured with at least one trust anchor. If the configured + key is a zone signing key, then it will authenticate the associated + zone; if the configured key is a key signing key, it will + authenticate a zone signing key. If the resolver has been configured + with the hash of a key rather than the key itself, the resolver may + need to obtain the key via a DNS query. To help security-aware + resolvers establish this authentication chain, security-aware name + servers attempt to send the signature(s) needed to authenticate a + zone's public key(s) in the DNS reply message along with the public + key itself, provided there is space available in the message. + + The Delegation Signer (DS) RR type simplifies some of the + administrative tasks involved in signing delegations across + organizational boundaries. The DS RRset resides at a delegation + point in a parent zone and indicates the public key(s) corresponding + to the private key(s) used to self-sign the DNSKEY RRset at the + delegated child zone's apex. The administrator of the child zone, in + turn, uses the private key(s) corresponding to one or more of the + public keys in this DNSKEY RRset to sign the child zone's data. The + typical authentication chain is therefore + DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more + DS->DNSKEY subchains. DNSSEC permits more complex authentication + chains, such as additional layers of DNSKEY RRs signing other DNSKEY + RRs within a zone. + + A security-aware resolver normally constructs this authentication + chain from the root of the DNS hierarchy down to the leaf zones based + on configured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to use one + or more configured public keys (or hashes of public keys) other than + the root public key, or may not provide configured knowledge of the + root public key, or may prevent the resolver from using particular + public keys for arbitrary reasons even if those public keys are + properly signed with verifiable signatures. DNSSEC provides + mechanisms by which a security-aware resolver can determine whether + an RRset's signature is "valid" within the meaning of DNSSEC. In the + final analysis however, authenticating both DNS keys and data is a + matter of local policy, which may extend or even override the + protocol extensions defined in this document set. See for further + discussion. + +3.2 Authenticating Name and Type Non-Existence + + The security mechanism described in Section 3.1 only provides a way + to sign existing RRsets in a zone. The problem of providing negative + responses with the same level of authentication and integrity + requires the use of another new resource record type, the NSEC + + + +Arends, et al. Expires November 15, 2004 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + record. The NSEC record allows a security-aware resolver to + authenticate a negative reply for either name or type non-existence + via the same mechanisms used to authenticate other DNS replies. Use + of NSEC records requires a canonical representation and ordering for + domain names in zones. Chains of NSEC records explicitly describe + the gaps, or "empty space", between domain names in a zone, as well + as listing the types of RRsets present at existing names. Each NSEC + record is signed and authenticated using the mechanisms described in + Section 3.1. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 10] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +4. Services Not Provided by DNS Security + + DNS was originally designed with the assumptions that the DNS will + return the same answer to any given query regardless of who may have + issued the query, and that all data in the DNS is thus visible. + Accordingly, DNSSEC is not designed to provide confidentiality, + access control lists, or other means of differentiating between + inquirers. + + DNSSEC provides no protection against denial of service attacks. + Security-aware resolvers and security-aware name servers are + vulnerable to an additional class of denial of service attacks based + on cryptographic operations. Please see Section 12 for details. + + The DNS security extensions provide data and origin authentication + for DNS data. The mechanisms outlined above are not designed to + protect operations such as zone transfers and dynamic update + [RFC3007]. Message authentication schemes described in [RFC2845] and + [RFC2931] address security operations that pertain to these + transactions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 11] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +5. Scope of the DNSSEC Document Set and Last Hop Issues + + The specification in this document set defines the behavior for zone + signers and security-aware name servers and resolvers in such a way + that the validating entities can unambiguously determine the state of + the data. + + A validating resolver can determine these 4 states: + + Secure: The validating resolver has a trust anchor, a chain of trust + and is able to verify all the signatures in the response. + + Insecure: The validating resolver has a trust anchor, a chain of + trust, and, at some delegation point, signed proof of the + non-existence of a DS record. That indicates that subsequent + branches in the tree are provably insecure. A validating resolver + may have local policy to mark parts of the domain space as + insecure. + + Bogus: The validating resolver has a trust anchor and there is a + secure delegation which is indicating that subsidiary data will be + signed, but the response fails to validate due to one or more + reasons: missing signatures, expired signatures, signatures with + unsupported algorithms, data missing which the relevant NSEC RR + says should be present, and so forth. + + Indeterminate: There is no trust anchor which would indicate that a + specific portion of the tree is secure. This is the default + operation mode. + + This specification only defines how security aware name servers can + signal non-validating stub resolvers that data was found to be bogus + (using RCODE=2, "Server Failure" -- see + [I-D.ietf-dnsext-dnssec-protocol]). + + There is a mechanism for security aware name servers to signal + security-aware stub resolvers that data was found to be secure (using + the AD bit, see [I-D.ietf-dnsext-dnssec-protocol]). + + This specification does not define a format for communicating why + responses were found to be bogus or marked as insecure. The current + signaling mechanism does not distinguish between indeterminate and + insecure. + + A method for signaling advanced error codes and policy between a + security aware stub resolver and security aware recursive nameservers + is a topic for future work, as is the interface between a security + aware resolver and the applications that use it. Note, however, that + + + +Arends, et al. Expires November 15, 2004 [Page 12] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + the lack of the specification of such communication does not prohibit + deployment of signed zones or the deployment of security aware + recursive name servers that prohibit propagation of bogus data to the + applications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 13] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +6. Resolver Considerations + + A security-aware resolver needs to be able to perform cryptographic + functions necessary to verify digital signatures using at least the + mandatory-to-implement algorithm(s). Security-aware resolvers must + also be capable of forming an authentication chain from a newly + learned zone back to an authentication key, as described above. This + process might require additional queries to intermediate DNS zones to + obtain necessary DNSKEY, DS and RRSIG records. A security-aware + resolver should be configured with at least one trust anchor as the + starting point from which it will attempt to establish authentication + chains. + + If a security-aware resolver is separated from the relevant + authoritative name servers by a recursive name server or by any sort + of device which acts as a proxy for DNS, and if the recursive name + server or proxy is not security-aware, the security-aware resolver + may not be capable of operating in a secure mode. For example, if a + security-aware resolver's packets are routed through a network + address translation device that includes a DNS proxy which is not + security-aware, the security-aware resolver may find it difficult or + impossible to obtain or validate signed DNS data. + + If a security-aware resolver must rely on an unsigned zone or a name + server that is not security aware, the resolver may not be able to + validate DNS responses, and will need a local policy on whether to + accept unverified responses. + + A security-aware resolver should take a signature's validation period + into consideration when determining the TTL of data in its cache, to + avoid caching signed data beyond the validity period of the + signature, but should also allow for the possibility that the + security-aware resolver's own clock is wrong. Thus, a security-aware + resolver which is part of a security-aware recursive name server will + need to pay careful attention to the DNSSEC "checking disabled" (CD) + bit [I-D.ietf-dnsext-dnssec-records]. This is in order to avoid + blocking valid signatures from getting through to other + security-aware resolvers which are clients of this recursive name + server. See [I-D.ietf-dnsext-dnssec-protocol] for how a secure + recursive server handles queries with the CD bit set. + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 14] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +7. Stub Resolver Considerations + + Although not strictly required to do so by the protocol, most DNS + queries originate from stub resolvers. Stub resolvers, by + definition, are minimal DNS resolvers which use recursive query mode + to offload most of the work of DNS resolution to a recursive name + server. Given the widespread use of stub resolvers, the DNSSEC + architecture has to take stub resolvers into account, but the + security features needed in a stub resolver differ in some respects + from those needed in a full security-aware resolver. + + Even a security-oblivious stub resolver may get some benefit from + DNSSEC if the recursive name servers it uses are security-aware, but + for the stub resolver to place any real reliance on DNSSEC services, + the stub resolver must trust both the recursive name servers in + question and the communication channels between itself and those name + servers. The first of these issues is a local policy issue: in + essence, a security-oblivious stub resolver has no real choice but to + place itself at the mercy of the recursive name servers that it uses, + since it does not perform DNSSEC validity checks on its own. The + second issue requires some kind of channel security mechanism; proper + use of DNS transaction authentication mechanisms such as SIG(0) or + TSIG would suffice, as would appropriate use of IPsec, and particular + implementations may have other choices available, such as operating + system specific interprocess communication mechanisms. + Confidentiality is not needed for this channel, but data integrity + and message authentication are. + + A security-aware stub resolver that does trust both its recursive + name servers and its communication channel to them may choose to + examine the setting of the AD bit in the message header of the + response messages it receives. The stub resolver can use this flag + bit as a hint to find out whether the recursive name server was able + to validate signatures for all of the data in the Answer and + Authority sections of the response. + + There is one more step that a security-aware stub resolver can take + if, for whatever reason, it is not able to establish a useful trust + relationship with the recursive name servers which it uses: it can + perform its own signature validation, by setting the Checking + Disabled (CD) bit in its query messages. A validating stub resolver + is thus able to treat the DNSSEC signatures as a trust relationship + between the zone administrator and the stub resolver itself. + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 15] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +8. Zone Considerations + + There are several differences between signed and unsigned zones. A + signed zone will contain additional security-related records (RRSIG, + DNSKEY, DS and NSEC records). RRSIG and NSEC records may be + generated by a signing process prior to serving the zone. The RRSIG + records that accompany zone data have defined inception and + expiration times, which establish a validity period for the + signatures and the zone data the signatures cover. + +8.1 TTL values vs. RRSIG validity period + + It is important to note the distinction between a RRset's TTL value + and the signature validity period specified by the RRSIG RR covering + that RRset. DNSSEC does not change the definition or function of the + TTL value, which is intended to maintain database coherency in + caches. A caching resolver purges RRsets from its cache no later than + the end of the time period specified by the TTL fields of those + RRsets, regardless of whether or not the resolver is security-aware. + + The inception and expiration fields in the RRSIG RR + [I-D.ietf-dnsext-dnssec-records], on the other hand, specify the time + period during which the signature can be used to validate the covered + RRset. The signatures associated with signed zone data are only + valid for the time period specified by these fields in the RRSIG RRs + in question. TTL values cannot extend the validity period of signed + RRsets in a resolver's cache, but the resolver may use the time + remaining before expiration of the signature validity period of a + signed RRset as an upper bound for the TTL of the signed RRset and + its associated RRSIG RR in the resolver's cache. + +8.2 New Temporal Dependency Issues for Zones + + Information in a signed zone has a temporal dependency which did not + exist in the original DNS protocol. A signed zone requires regular + maintenance to ensure that each RRset in the zone has a current valid + RRSIG RR. The signature validity period of an RRSIG RR is an + interval during which the signature for one particular signed RRset + can be considered valid, and the signatures of different RRsets in a + zone may expire at different times. Re-signing one or more RRsets in + a zone will change one or more RRSIG RRs, which in turn will require + incrementing the zone's SOA serial number to indicate that a zone + change has occurred and re-signing the SOA RRset itself. Thus, + re-signing any RRset in a zone may also trigger DNS NOTIFY messages + and zone transfers operations. + + + + + + +Arends, et al. Expires November 15, 2004 [Page 16] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +9. Name Server Considerations + + A security-aware name server should include the appropriate DNSSEC + records (RRSIG, DNSKEY, DS and NSEC) in all responses to queries from + resolvers which have signaled their willingness to receive such + records via use of the DO bit in the EDNS header, subject to message + size limitations. Since inclusion of these DNSSEC RRs could easily + cause UDP message truncation and fallback to TCP, a security-aware + name server must also support the EDNS "sender's UDP payload" + mechanism. + + If possible, the private half of each DNSSEC key pair should be kept + offline, but this will not be possible for a zone for which DNS + dynamic update has been enabled. In the dynamic update case, the + primary master server for the zone will have to re-sign the zone when + updated, so the private key corresponding to the zone signing key + will have to be kept online. This is an example of a situation where + the ability to separate the zone's DNSKEY RRset into zone signing + key(s) and key signing key(s) may be useful, since the key signing + key(s) in such a case can still be kept offline and may have a longer + useful lifetime than the zone signing key(s). + + DNSSEC, by itself, is not enough to protect the integrity of an + entire zone during zone transfer operations, since even a signed zone + contains some unsigned, nonauthoritative data if the zone has any + children. Therefore, zone maintenance operations will require some + additional mechanisms (most likely some form of channel security, + such as TSIG, SIG(0), or IPsec). + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 17] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +10. DNS Security Document Family + + The DNSSEC document set can be partitioned into several main groups, + under the larger umbrella of the DNS base protocol documents. + + The "DNSSEC protocol document set" refers to the three documents + which form the core of the DNS security extensions: + 1. DNS Security Introduction and Requirements (this document) + 2. Resource Records for DNS Security Extensions + [I-D.ietf-dnsext-dnssec-records] + 3. Protocol Modifications for the DNS Security Extensions + [I-D.ietf-dnsext-dnssec-protocol] + + Additionally, any document that would add to, or change the core DNS + Security extensions would fall into this category. This includes any + future work on the communication between security-aware stub + resolvers and upstream security-aware recursive name servers. + + The "Digital Signature Algorithm Specification" document set refers + to the group of documents that describe how specific digital + signature algorithms should be implemented to fit the DNSSEC resource + record format. Each document in this set deals with a specific + digital signature algorithm. + + The "Transaction Authentication Protocol" document set refers to the + group of documents that deal with DNS message authentication, + including secret key establishment and verification. While not + strictly part of the DNSSEC specification as defined in this set of + documents, this group is noted because of its relationship to DNSSEC. + + The final document set, "New Security Uses", refers to documents that + seek to use proposed DNS Security extensions for other security + related purposes. DNSSEC does not provide any direct security for + these new uses, but may be used to support them. Documents that fall + in this category include the use of DNS in the storage and + distribution of certificates [RFC2538]. + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 18] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +11. IANA Considerations + + This overview document introduces no new IANA considerations. Please + see [I-D.ietf-dnsext-dnssec-records] for a complete review of the + IANA considerations introduced by DNSSEC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 19] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +12. Security Considerations + + This document introduces the DNS security extensions and describes + the document set that contains the new security records and DNS + protocol modifications. The extensions provide data origin + authentication and data integrity using digital signatures over + resource record sets.This document discusses the capabilities and + limitations of these extensions. + + In order for a security-aware resolver to validate a DNS response, + all zones along the path from the trusted starting point to the zone + containing the response zones must be signed, and all name servers + and resolvers involved in the resolution process must be + security-aware, as defined in this document set. A security-aware + resolver cannot verify responses originating from an unsigned zone, + from a zone not served by a security-aware name server, or for any + DNS data which the resolver is only able to obtain through a + recursive name server which is not security-aware. If there is a + break in the authentication chain such that a security-aware resolver + cannot obtain and validate the authentication keys it needs, then the + security-aware resolver cannot validate the affected DNS data. + + This document briefly discusses other methods of adding security to a + DNS query, such as using a channel secured by IPsec or using a DNS + transaction authentication mechanism, but transaction security is not + part of DNSSEC per se. + + A non-validating security-aware stub resolver, by definition, does + not perform DNSSEC signature validation on its own, and thus is + vulnerable both to attacks on (and by) the security-aware recursive + name servers which perform these checks on its behalf and also to + attacks on its communication with those security-aware recursive name + servers. Non-validating security-aware stub resolvers should use some + form of channel security to defend against the latter threat. The + only known defense against the former threat would be for the + security-aware stub resolver to perform its own signature validation, + at which point, again by definition, it would no longer be a + non-validating security-aware stub resolver. + + DNSSEC does not protect against denial of service attacks. DNSSEC + makes DNS vulnerable to a new class of denial of service attacks + based on cryptographic operations against security-aware resolvers + and security-aware name servers, since an attacker can attempt to use + DNSSEC mechanisms to consume a victim's resources. This class of + attacks takes at least two forms. An attacker may be able to consume + resources in a security-aware resolver's signature validation code by + tampering with RRSIG RRs in response messages or by constructing + needlessly complex signature chains. An attacker may also be able to + + + +Arends, et al. Expires November 15, 2004 [Page 20] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + consume resources in a security-aware name server which supports DNS + dynamic update, by sending a stream of update messages that force the + security-aware name server to re-sign some RRsets in the zone more + frequently than would otherwise be necessary. + + DNSSEC introduces the ability for a hostile party to enumerate all + the names in a zone by following the NSEC chain. NSEC RRs assert + which names do not exist in a zone by linking from existing name to + existing name along a canonical ordering of all the names within a + zone. Thus, an attacker can query these NSEC RRs in sequence to + obtain all the names in a zone. While not an attack on the DNS + itself, this could allow an attacker to map network hosts or other + resources by enumerating the contents of a zone. There are non-DNS + protocol means of detecting and limiting this attack beyond the scope + of this document set. + + DNSSEC introduces significant additional complexity to the DNS, and + thus introduces many new opportunities for implementation bugs and + misconfigured zones. In particular, enabling DNSSEC signature + validation in a resolver may cause entire legitimate zones to become + effectively unreachable due to DNSSEC configuration errors or bugs. + + DNSSEC does not provide confidentiality, due to a deliberate design + choice. + + DNSSEC does not protect against tampering with unsigned zone data. + Non-authoritative data at zone cuts (glue and NS RRs in the parent + zone) are not signed. This does not pose a problem when validating + the authentication chain, but does mean that the non-authoritative + data itself is vulnerable to tampering during zone transfer + operations. Thus, while DNSSEC can provide data origin + authentication and data integrity for RRsets, it cannot do so for + zones, and other mechanisms must be used to protect zone transfer + operations. + + Please see [I-D.ietf-dnsext-dnssec-records] and + [I-D.ietf-dnsext-dnssec-protocol] for additional security + considerations. + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +13. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group. While explicitly listing everyone + who has contributed during the decade during which DNSSEC has been + under development would be an impossible task, the editors would + particularly like to thank the following people for their + contributions to and comments on this document set: Mark Andrews, + Derek Atkins, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, + Randy Bush, Francis Dupont, Donald Eastlake, Miek Gieben, Michael + Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Phillip + Hallam-Baker, Walter Howard, Stephen Jacob, Simon Josefsson, Olaf + Kolkman, Mark Kosters, David Lawrence, Ted Lemon, Ed Lewis, Ted + Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Mans Nilsson, + Masataka Ohta, Rob Payne, Jim Reid, Michael Richardson, Erik + Rozendaal, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, and + Brian Wellington. + + No doubt the above list is incomplete. We apologize to anyone we + left out. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +14. References + +14.1 Normative References + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in + progress), May 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-08 (work in progress), + May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + +14.2 Informative References + + [I-D.ietf-dnsext-dns-threats] + Atkins, D. and R. Austein, "Threat Analysis Of The Domain + Name System", draft-ietf-dnsext-dns-threats-07 (work in + progress), April 2004. + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "KEY RR Secure Entry Point Flag", + draft-ietf-dnsext-nsec-rdata-05 (work in progress), March + 2004. + + + +Arends, et al. Expires November 15, 2004 [Page 23] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in + the Domain Name System (DNS)", RFC 2538, March 1999. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, May 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) + Signing Authority", RFC 3008, November 2000. + + [RFC3090] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", RFC 3755, April 2004. + + [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", RFC 3757, April 2004. + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 24] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + +Arends, et al. Expires November 15, 2004 [Page 25] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires November 15, 2004 [Page 26] + +Internet-Draft DNSSEC Introduction and Requirements May 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 27] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt new file mode 100644 index 0000000000..a6f628e3c7 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-06.txt @@ -0,0 +1,3249 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: November 15, 2004 M. Larson + VeriSign + R. Austein + ISC + D. Massey + USC/ISI + S. Rose + NIST + May 17, 2004 + + + Protocol Modifications for the DNS Security Extensions + draft-ietf-dnsext-dnssec-protocol-06 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 15, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents which describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications which + add data origin authentication and data integrity to the DNS. This + document describes the DNSSEC protocol modifications. This document + + + +Arends, et al. Expires November 15, 2004 [Page 1] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + defines the concept of a signed zone, along with the requirements for + serving and resolving using DNSSEC. These techniques allow a + security-aware resolver to authenticate both DNS resource records and + authoritative DNS error indications. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . 4 + 1.3.2 Technical Changes or Corrections . . . . . . . . . . . 4 + 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . 5 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . 6 + 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . 6 + 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . 7 + 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . 8 + 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . 8 + 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . 9 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . 11 + 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . 11 + 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . 12 + 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . 12 + 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . 15 + 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . 16 + 3.1.6 The AD and CD Bits in an Authoritative Response . . . 17 + 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . 17 + 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . 18 + 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . 19 + 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . 19 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . 20 + 4.2 Signature Verification Support . . . . . . . . . . . . . . 20 + 4.3 Determining Security Status of Data . . . . . . . . . . . 21 + 4.4 Configured Trust Anchors . . . . . . . . . . . . . . . . . 21 + 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . 22 + 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . 22 + 4.7 Caching BAD Data . . . . . . . . . . . . . . . . . . . . . 22 + 4.8 Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . . 23 + 4.9 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . 23 + 4.9.1 Handling of the DO Bit . . . . . . . . . . . . . . . . 24 + + + +Arends, et al. Expires November 15, 2004 [Page 2] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + 4.9.2 Handling of the CD Bit . . . . . . . . . . . . . . . . 24 + 4.9.3 Handling of the AD Bit . . . . . . . . . . . . . . . . 24 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 + 5.1 Special Considerations for Islands of Security . . . . . . 26 + 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . 26 + 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . 27 + 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . 28 + 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . 28 + 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . 30 + 5.3.4 Authenticating A Wildcard Expanded RRset Positive + Response . . . . . . . . . . . . . . . . . . . . . . . 31 + 5.4 Authenticated Denial of Existence . . . . . . . . . . . . 31 + 5.5 Resolver Behavior When Signatures Do Not Validate . . . . 32 + 5.6 Authentication Example . . . . . . . . . . . . . . . . . . 32 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 36 + 9.2 Informative References . . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 39 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 45 + B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . 45 + B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 46 + B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 47 + B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 48 + B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 49 + B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 50 + B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 51 + B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 52 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 54 + C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . 54 + C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . 54 + C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . 55 + C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . 55 + C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . 55 + C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . 55 + C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 56 + C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . 56 + C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . 56 + Intellectual Property and Copyright Statements . . . . . . . . 57 + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 3] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications which add data origin + authentication and data integrity to the DNS. This document defines + the DNSSEC protocol modifications. Section 2 of this document defines + the concept of a signed zone and lists the requirements for zone + signing. Section 3 describes the modifications to authoritative name + server behavior necessary to handle signed zones. Section 4 describes + the behavior of entities which include security-aware resolver + functions. Finally, Section 5 defines how to use DNSSEC RRs to + authenticate a response. + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in [RFC1034] and [RFC1035]. + + This document is part of a family of documents that define DNSSEC. + An introduction to DNSSEC and definition of common terms can be found + in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC + resource records can be found in [I-D.ietf-dnsext-dnssec-records]. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. [RFC2119]. + +1.3 Editors' Notes + +1.3.1 Open Technical Issues + +1.3.2 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + + + + +Arends, et al. Expires November 15, 2004 [Page 4] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +1.3.3 Typos and Minor Corrections + + Please report any typos corrections to dnssec-editors@east.isi.edu. + To assist the editors, please provide enough context for us to find + the incorrect text quickly. + + An example message to dnssec-editors might be: page X says "the + DNSSEC standard has been in development for over 1 years". It + should read "over 10 years". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 5] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +2. Zone Signing + + DNSSEC introduces the concept of signed zones. A signed zone + includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to + the rules specified in Section 2.1, Section 2.2, Section 2.3 and + Section 2.4, respectively. A zone that does not include these + records according to the rules in this section is an unsigned zone. + + DNSSEC requires a change to the definition of the CNAME resource + record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG + and NSEC RRs to appear at the same owner name as a CNAME RR. + +2.1 Including DNSKEY RRs in a Zone + + To sign a zone, the zone's administrator generates one or more + public/private key pairs and uses the private key(s) to sign + authoritative RRsets in the zone. For each private key used to + create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with + the public component stored in the zone. A zone key DNSKEY RR MUST + have the Zone Key bit of the flags RDATA field set to one -- see + Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys + associated with other DNS operations MAY be stored in DNSKEY RRs that + are not marked as zone keys but MUST NOT be used to verify RRSIGs. + + If the zone is delegated and does not wish to act as an island of + security, the zone MUST have at least one DNSKEY RR at the apex to + act as a secure entry point into the zone. This DNSKEY would then be + used to generate a DS RR at the delegating parent (see + [I-D.ietf-dnsext-dnssec-records]). + + DNSKEY RRs MUST NOT appear at delegation points. + +2.2 Including RRSIG RRs in a Zone + + For each authoritative RRset in a signed zone, there MUST be at least + one RRSIG record that meets all of the following requirements: + o The RRSIG owner name is equal to the RRset owner name; + o The RRSIG class is equal to the RRset class; + o The RRSIG Type Covered field is equal to the RRset type; + o The RRSIG Original TTL field is equal to the TTL of the RRset; + o The RRSIG RR's TTL is equal to the TTL of the RRset; + o The RRSIG Labels field is equal to the number of labels in the + RRset owner name, not counting the null root label and not + counting the leftmost label if it is a wildcard; + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset; and + o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a + zone key DNSKEY record at the zone apex. + + + +Arends, et al. Expires November 15, 2004 [Page 6] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + The process for constructing the RRSIG RR for a given RRset is + described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have + multiple RRSIG RRs associated with it. + + An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR + would add no value and would create an infinite loop in the signing + process. + + The NS RRset that appears at the zone apex name MUST be signed, but + the NS RRsets that appear at delegation points (that is, the NS + RRsets in the parent zone that delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated with + delegations MUST NOT be signed. + + There MUST be an RRSIG for each RRset using at least one DNSKEY of + each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset + itself MUST be signed by each algorithm appearing in the DS RRset + located at the delegating parent (if any). + +2.3 Including NSEC RRs in a Zone + + Each owner name in the zone which has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + process for constructing the NSEC RR for a given name is described in + [I-D.ietf-dnsext-dnssec-records]. + + The TTL value for any NSEC RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRset at any particular owner name. That is, the signing process + MUST NOT create NSEC or RRSIG RRs for owner names nodes which were + not the owner name of any RRset before the zone was signed. The main + reasons for this are a desire for namespace consistency between + signed and unsigned versions of the same zone and a desire to reduce + the risk of response inconsistency in security oblivious recursive + name servers. + + The type bitmap of every NSEC resource record in a signed zone MUST + indicate the presence of both the NSEC record itself and its + corresponding RRSIG record. + + The difference between the set of owner names that require RRSIG + records and the set of owner names that require NSEC records is + subtle and worth highlighting. RRSIG records are present at the + owner names of all authoritative RRsets. NSEC records are present at + the owner names of all names for which the signed zone is + authoritative and also at the owner names of delegations from the + + + +Arends, et al. Expires November 15, 2004 [Page 7] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + signed zone to its children. Neither NSEC nor RRSIG records are + present (in the parent zone) at the owner names of glue address + RRsets. Note, however, that this distinction is for the most part is + only visible during the zone signing process, because NSEC RRsets are + authoritative data, and are therefore signed, thus any owner name + which has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and the RR + types for which the parent zone has authoritative data MUST be set to + 1; bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be set to 0. + +2.4 Including DS RRs in a Zone + + The DS resource record establishes authentication chains between DNS + zones. A DS RRset SHOULD be present at a delegation point when the + child zone is signed. The DS RRset MAY contain multiple records, + each referencing a public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS + RRsets MUST NOT appear at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR which is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. + + The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset + (i.e., the NS RRset from the same zone containing the DS RRset). + + Construction of a DS RR requires knowledge of the corresponding + DNSKEY RR in the child zone, which implies communication between the + child and parent zones. This communication is an operational matter + not covered by this document. + +2.5 Changes to the CNAME Resource Record. + + If a CNAME RRset is present at a name in a signed zone, appropriate + RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that + name for secure dynamic update purposes is also allowed. Other types + MUST NOT be present at that name. + + This is a modification to the original CNAME definition given in + [RFC1034]. The original definition of the CNAME RR did not allow any + other types to coexist with a CNAME record, but a signed zone + requires NSEC and RRSIG RRs for every authoritative name. To resolve + this conflict, this specification modifies the definition of the + CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + + + +Arends, et al. Expires November 15, 2004 [Page 8] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +2.6 Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 9] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +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. Functions specific to security-aware recursive name + servers are described in Section 3.2; functions specific to + authoritative servers are described in Section 3.1. + + The terms "SNAME", "SCLASS", and "STYPE" in the following discussion + are as used in [RFC1034]. + + 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 [RFC3226]. + + 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 set to zero + 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. Since the DS RR type has the peculiar property of + only existing in the parent zone at delegation points, DS RRs always + require some special processing, as described in Section 3.1.4.1. + + Security aware name servers that receive queries for security RR + types which match the content of more than one zone that it serves + (e.g. NSEC and RRSIG RRs above and below a delegation point where the + server is authoritative for both zones) are encouraged to behave + self-consistently. The name server MAY return one of the following: + o The above-delegation RRsets + o The below-delegation RRsets + o Both above and below-delegation RRsets + o Empty answer section (i.e. no records) + o Some other response + o An error + As long as the response is always consistent for each query to the + name server. + + DNSSEC allocates two new bits in the DNS message header: the CD + (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit + is controlled by resolvers; a security-aware name server MUST copy + the CD bit from a query into the corresponding response. The AD bit + is controlled by name servers; a security-aware name server MUST + ignore the setting of the AD bit in queries. See Section 3.1.6, + Section 3.2.2, Section 3.2.3, Section 4, and Section 4.9 for details + on the behavior of these bits. + + + + +Arends, et al. Expires November 15, 2004 [Page 10] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + A security aware name server which synthesizes CNAME RRs from DNAME + RRs as described in [RFC2672] SHOULD NOT generate signatures for the + synthesized CNAME RRs. + +3.1 Authoritative Name Servers + + Upon receiving a relevant query that has the EDNS [RFC2671] OPT + pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative + name server for a signed zone MUST include additional RRSIG, NSEC, + and DS RRs according to the following rules: + o 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; + o 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; + o 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. + + DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 + discusses zone transfer requirements. + +3.1.1 Including RRSIG RRs in a Response + + When responding to a query that has the DO bit set to one, 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. A name server SHOULD make every attempt to keep the + RRset and its associated RRSIG(s) together in a response. Inclusion + of RRSIG RRs in a response is subject to the following rules: + o When placing a signed RRset in the Answer section, the name server + MUST also place its RRSIG RRs in the Answer section. The RRSIG + RRs have a higher priority for inclusion than any other RRsets + that may need to be included. If space does not permit inclusion + of these RRSIG RRs, the name server MUST set the TC bit. + o When placing a signed RRset in the Authority section, the name + server MUST also place its RRSIG RRs in the Authority section. + The RRSIG RRs have a higher priority for inclusion than any other + RRsets that may need to be included. If space does not permit + inclusion of these RRSIG RRs, the name server MUST set the TC bit. + o 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 both the RRset and its + associated RRSIG RRs, the name server MAY drop the RRSIG RRs. If + this happens, the name server MUST NOT set the TC bit solely + because these RRSIG RRs didn't fit. + + + + + +Arends, et al. Expires November 15, 2004 [Page 11] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +3.1.2 Including DNSKEY RRs In a Response + + When responding to a query that has the DO bit set to one 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. In this situation, + the DNSKEY RRset and associated RRSIG RRs have lower priority than + any other information that would be placed in the additional section. + The name server SHOULD NOT include the DNSKEY RRset unless there is + enough space in the response message for both the DNSKEY RRset and + its associated RRSIG RR(s). If there is not enough space to include + these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST + NOT set the TC bit solely because these RRs didn't fit (see Section + 3.1.1). + +3.1.3 Including NSEC RRs In a Response + + When responding to a query that has the DO bit set to one, 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 , + but does not contain any RRsets that exactly match . + + Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match but does contain an RRset that matches + via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match , does contain one or more RRsets that match + via wildcard name expansion, but does not contain + any RRsets that match via wildcard name + expansion. + + In each of these cases, the name server includes NSEC RRs in the + response to prove that an exact match for was + not present in the zone and that the response that the name server is + returning is correct given the data that are in the zone. + +3.1.3.1 Including NSEC RRs: No Data Response + + If the zone contains RRsets matching but contains no + RRset matching , then the name server MUST + include the NSEC RR for along with its associated + + + +Arends, et al. Expires November 15, 2004 [Page 12] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + RRSIG RR(s) in the Authority section of the response (see Section + 3.1.1). If space does not permit inclusion of the NSEC RR or its + associated RRSIG RR(s), the name server MUST set the TC bit (see + Section 3.1.1). + + Since the search name exists, wildcard name expansion does not apply + to this query, and a single signed NSEC RR suffices to prove the + requested RR type does not exist. + +3.1.3.2 Including NSEC RRs: Name Error Response + + If the zone does not contain any RRsets matching + either exactly or via wildcard name expansion, then the name server + MUST include the following NSEC RRs in the Authority section, along + with their associated RRSIG RRs: + o An NSEC RR proving that there is no exact match for ; and + o An NSEC RR proving that the zone contains no RRsets that would + match via wildcard name expansion. + + In some cases a single NSEC RR may prove both of these points, in + that case the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + Note that this form of response includes cases in which SNAME + corresponds to an empty non-terminal name within the zone (a name + which is not the owner name for any RRset but which is the parent + name of one or more RRsets). + +3.1.3.3 Including NSEC RRs: Wildcard Answer Response + + If the zone does not contain any RRsets which exactly match but does contain an RRset which matches 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 and associated RRSIG RR(s) proving that the zone + does not contain a closer match for . If space does + not permit inclusion of the answer, NSEC and RRSIG RRs, the name + server MUST set the TC bit (see Section 3.1.1). + + + + +Arends, et al. Expires November 15, 2004 [Page 13] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +3.1.3.4 Including NSEC RRs: Wildcard No Data Response + + This case is a combination of the previous cases. The zone does not + contain an exact match for , and while the zone does + contain RRsets which match via wildcard expansion, + none of those RRsets match STYPE. The name server MUST include the + following NSEC RRs in the Authority section, along with their + associated RRSIG RRs: + o An NSEC RR proving that there are no RRsets matching STYPE at the + wildcard owner name which matched via wildcard + expansion; and + o An NSEC RR proving that there are no RRsets in the zone which + would have been a closer match for . + + In some cases a single NSEC RR may prove both of these points, in + which case the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + +3.1.3.5 Finding The Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server needs to locate an NSEC RR + which proves that no RRsets matching a particular SNAME exist. + Locating such an NSEC RR within an authoritative zone is relatively + simple, at least in concept. The following discussion assumes that + the name server is authoritative for the zone which would have held + the nonexistent RRsets matching SNAME. The algorithm below is + written for clarity, not efficiency. + + To find the NSEC which proves that no RRsets matching name N exist in + the zone Z which would have held them, construct sequence S + consisting of the owner names of every RRset in Z, sorted into + canonical order [I-D.ietf-dnsext-dnssec-records], with no duplicate + names. Find the name M which would have immediately preceded N in S + if any RRsets with owner name N had existed. M is the owner name of + the NSEC RR which proves that no RRsets exist with owner name N. + + The algorithm for finding the NSEC RR which proves that a given name + is not covered by any applicable wildcard is similar, but requires an + extra step. More precisely, the algorithm for finding the NSEC + proving that no RRsets exist with the applicable wildcard name is + + + +Arends, et al. Expires November 15, 2004 [Page 14] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + precisely the same as the algorithm for finding the NSEC RR which + proves that RRsets with any other owner name do not exist: the part + that's missing is how to determine the name of the nonexistent + applicable wildcard. In practice, this is easy, because the + authoritative name server has already checked for the presence of + precisely this wildcard name as part of step (1)(c) of the normal + lookup algorithm described in Section 4.3.2 of [RFC1034]. + +3.1.4 Including DS RRs In a Response + + When responding to a query which has the DO bit set to one, a + security-aware authoritative name server returning a referral + includes DNSSEC data along with the NS RRset. + + If a DS RRset is present at the delegation point, the name server + MUST return both the DS RRset and its associated RRSIG RR(s) in the + Authority section along with the NS RRset. The name server MUST + place the NS RRset before the DS RRset and its associated RRSIG + RR(s). + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR which proves that the DS RRset is not + present and the NSEC RR's associated RRSIG RR(s) along with the NS + RRset. The name server MUST place the NS RRset before the NSEC RRset + and its associated RRSIG RR(s). + + Including these DS, NSEC, and RRSIG RRs increases the size of + referral messages, and may cause some or all glue RRs to be omitted. + If space does not permit inclusion of the DS or NSEC RRset and + associated RRSIG RRs, the name server MUST set the TC bit (see + Section 3.1.1). + +3.1.4.1 Responding to Queries for DS RRs + + The DS resource record type is unusual in that it appears only on the + parent zone's side of a zone cut. For example, the DS RRset for the + delegation of "foo.example" is stored in the "example" zone rather + than in the "foo.example" zone. This requires special processing + rules for both name servers and resolvers, since the name server for + the child zone is authoritative for the name at the zone cut by the + normal DNS rules but the child zone does not contain the DS RRset. + + A security-aware resolver sends queries to the parent zone when + looking for a needed DS RR at a delegation point (see Section 4.2). + However, special rules are necessary to avoid confusing + security-oblivious resolvers which might become involved in + processing such a query (for example, in a network configuration that + forces a security-aware resolver to channel its queries through a + + + +Arends, et al. Expires November 15, 2004 [Page 15] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + security-oblivious recursive name server). The rest of this section + describes how a security-aware name server processes DS queries in + order to avoid this problem. + + The need for special processing by a security-aware name server only + arises when all the following conditions are met: + o the name server has received a query for the DS RRset at a zone + cut; and + o the name server is authoritative for the child zone; and + o the name server is not authoritative for the parent zone; and + o the name server does not offer recursion. + + In all other cases, the name server either has some way of obtaining + the DS RRset or could not have been expected to have the DS RRset + even by the pre-DNSSEC processing rules, so the name server can + return either the DS RRset or an error response according to the + normal processing rules. + + If all of the above conditions are met, however, the name server is + authoritative for SNAME but cannot supply the requested RRset. In + this case, the name server MUST return an authoritative "no data" + response showing that the DS RRset does not exist in the child zone's + apex. See Appendix B.8 for an example of such a response. + +3.1.5 Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation. + + An authoritative name server is not required to verify that a zone is + properly signed before sending or accepting a zone transfer. + However, an authoritative name server MAY choose to reject the entire + zone transfer if the zone fails meets any of the signing requirements + described in Section 2. The primary objective of a zone transfer is + to ensure that all authoritative name servers have identical copies + of the zone. An authoritative name server that chooses to perform + its own zone validation MUST NOT selectively reject some RRs and + accept others. + + DS RRsets appear only on the parental side of a zone cut and are + authoritative data in the parent zone. As with any other + authoritative RRset, the DS RRset MUST be included in zone transfers + of the zone in which the RRset is authoritative data: in the case of + the DS RRset, this is the parent zone. + + NSEC RRs appear in both the parent and child zones at a zone cut, and + + + +Arends, et al. Expires November 15, 2004 [Page 16] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + are authoritative data in both the parent and child zones. The + parental and child NSEC RRs at a zone cut are never identical to each + other, since the NSEC RR in the child zone's apex will always + indicate the presence of the child zone's SOA RR while the parental + NSEC RR at the zone cut will never indicate the presence of an SOA + RR. As with any other authoritative RRs, NSEC RRs MUST be included + in zone transfers of the zone in which they are authoritative data: + the parental NSEC RR at a zone cut MUST be included zone transfers of + the parent zone, while the NSEC at the zone apex of the child zone + MUST be included in zone transfers of the child zone. + + RRSIG RRs appear in both the parent and child zones at a zone cut, + and are authoritative in whichever zone contains the authoritative + RRset for which the RRSIG RR provides the signature. That is, the + RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be + authoritative in the parent zone, while the RRSIG for any RRset in + the child zone's apex will be authoritative in the child zone. As + with any other authoritative RRs, RRSIG RRs MUST be included in zone + transfers of the zone in which they are authoritative data. + +3.1.6 The AD and CD Bits in an Authoritative Response + + The CD and AD bits are designed for use in communication between + security-aware resolvers and security-aware recursive name servers. + These bits are for the most part not relevant to query processing by + security-aware authoritative name servers. + + A security-aware name server does not perform signature validation + for authoritative data during query processing even when the CD bit + is set to zero. A security-aware name server SHOULD clear the CD bit + when composing an authoritative response. + + A security-aware name server MUST NOT set the AD bit in a response + unless the name server considers all RRsets in the Answer and + Authority sections of the response to be authentic. A security-aware + name server's local policy MAY consider data from an authoritative + zone to be authentic without further validation, but the name server + MUST NOT do so unless the name server obtained the authoritative zone + via secure means (such as a secure zone transfer mechanism), and MUST + NOT do so unless this behavior has been configured explicitly. + + A security-aware name server which supports recursion MUST follow the + rules for the CD and AD bits given in Section 3.2 when generating a + response that involves data obtained via recursion. + +3.2 Recursive Name Servers + + As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware + + + +Arends, et al. Expires November 15, 2004 [Page 17] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + recursive name server is an entity which acts in both the + security-aware name server and security-aware resolver roles. This + section uses the terms "name server side" and "resolver side" to + refer to the code within a security-aware recursive name server which + implements the security-aware name server role and the code which + implements the security-aware resolver role, respectively. + + The resolver side follows the usual rules for caching and negative + caching which would apply to any security-aware resolver. + +3.2.1 The DO bit + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the DO bit in an initiating query is not set, the name server side + MUST strip any authenticating DNSSEC RRs from the response, but MUST + NOT strip any DNSSEC RR types that the initiating query explicitly + requested. + +3.2.2 The CD bit + + The CD bit exists in order to allow a security-aware resolver to + disable signature validation in a security-aware name server's + processing of a particular query. + + The name server side MUST copy the setting of the CD bit from a query + to the corresponding response. + + The name server side of a security-aware recursive name server MUST + pass the sense of the CD bit to the resolver side along with the rest + of an initiating query, so that the resolver side will know whether + or not it is required to verify the response data it returns to the + name server side. If the CD bit is set to one, it indicates that the + originating resolver is willing to perform whatever authentication + its local policy requires, thus the resolver side of the recursive + name server need not perform authentication on the RRsets in the + response. When the CD bit is set to one the recursive name server + SHOULD, if possible, return the requested data to the originating + resolver even if the recursive name server's local authentication + policy would reject the records in question. That is, by setting the + CD bit, the originating resolver has indicated that it takes + responsibility for performing its own authentication, and the + recursive name server should not interfere. + + If the resolver side implements a BAD cache (see Section 4.7) and the + name server side receives a query which matches an entry in the + resolver side's BAD cache, the name server side's response depends on + + + +Arends, et al. Expires November 15, 2004 [Page 18] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + the sense of the CD bit in the original query. If the CD bit is set, + the name server side SHOULD return the data from the BAD cache; if + the CD bit is not set, the name server side MUST return RCODE 2 + (server failure). + + The intent of the above rule is to provide the raw data to clients + which are capable of performing their own signature verification + checks while protecting clients which depend on the resolver side of + a security-aware recursive name server to perform such checks. + Several of the possible reasons why signature validation might fail + involve conditions which may not apply equally to the recursive name + server and the client which invoked it: for example, the recursive + name server's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security which the recursive name + server does not share. In such cases, "protecting" a client which is + capable of performing its own signature validation from ever seeing + the "bad" data does not help the client. + +3.2.3 The AD bit + + The name server side of a security-aware recursive name server MUST + NOT set the AD bit in a response unless the name server considers all + RRsets in the Answer and Authority sections of the response to be + authentic. The name server side SHOULD set the AD bit if and only if + the resolver side considers all RRsets in the Answer section and any + relevant negative response RRs in the Authority section to be + authentic. The resolver side MUST follow the procedure described in + Section 5 to determine whether the RRs in question are authentic. + However, for backwards compatibility, a recursive name server MAY set + the AD bit when a response includes unsigned CNAME RRs if those CNAME + RRs demonstrably could have been synthesized from an authentic DNAME + RR which is also included in the response according to the synthesis + rules described in [RFC2672]. + +3.3 Example DNSSEC Responses + + See Appendix B for example response packets. + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 19] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +4. Resolving + + This section describes the behavior of entities that include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in + Section 3.2. + +4.1 EDNS Support + + A security-aware resolver MUST include an EDNS [RFC2671] OPT + pseudo-RR with the DO [RFC3225] bit set to one when sending queries. + + A security-aware resolver MUST support a message size of at least + 1220 octets, SHOULD support a message size of 4000 octets, and MUST + advertise the supported message size using the "sender's UDP payload + size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST + handle fragmented UDP packets correctly regardless of whether any + such fragmented packets were received via IPv4 or IPv6. Please see + [RFC3226] for discussion of these requirements. + +4.2 Signature Verification Support + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5, and MUST apply them to every + received response except when: + o The security-aware resolver is part of a security-aware recursive + name server, and the response is the result of recursion on behalf + of a query received with the CD bit set; + o The response is the result of a query generated directly via some + form of application interface which instructed the security-aware + resolver not to perform validation for this query; or + o Validation for this query has been disabled by local policy. + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + Security aware resolvers MAY query for missing security RRs in an + attempt to perform validation; implementations that choose to do so + must be aware of the fact that the answers received may not be + sufficient to validate the original response. + + When attempting to retrieve missing NSEC RRs which reside on the + parental side at a zone cut, a security-aware iterative-mode resolver + MUST query the name servers for the parent zone, not the child zone. + + When attempting to retrieve a missing DS, a security-aware + + + +Arends, et al. Expires November 15, 2004 [Page 20] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + iterative-mode resolver MUST query the name servers for the parent + zone, not the child zone. As explained in Section 3.1.4.1, + security-aware name servers need to apply special processing rules to + handle the DS RR, and in some situations the resolver may also need + to apply special rules to locate the name servers for the parent zone + if the resolver does not already have the parent's NS RRset. To + locate the parent NS RRset, the resolver can start with the + delegation name, strip off the leftmost label, and query for an NS + RRset by that name; if no NS RRset is present at that name, the + resolver then strips of the leftmost remaining label and retries the + query for that name, repeating this process of walking up the tree + until it either finds the NS RRset or runs out of labels. + +4.3 Determining Security Status of Data + + A security-aware resolver MUST be able to determine whether or not it + should expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between four + cases: + + Secure: An RRset for which the resolver is able to build a chain of + signed DNSKEY and DS RRs from a trusted security anchor to the + RRset. In this case, the RRset should be signed, and is subject + to signature validation as described above. + + Insecure: An RRset for which the resolver knows that it has no chain + of signed DNSKEY and DS RRs from any trusted starting point to the + RRset. This can occur when the target RRset lies in an unsigned + zone or in a descendent of an unsigned zone. In this case, the + RRset may or may not be signed, but the resolver will not be able + to verify the signature. + + Bogus: An RRset for which the resolver believes that it ought to be + able to establish a chain of trust but is unable to do so, either + due to signatures that for some reason fail to validate or due to + missing data which the relevant DNSSEC RRs indicate should be + present. This case may indicate an attack, but may also indicate + a configuration error or some form of data corruption. + + Indeterminate: An RRset for which the resolver is not able to + determine whether or not the RRset should be signed, because the + resolver is not able to obtain the necessary DNSSEC RRs. This can + occur when the security-aware resolver is not able to contact + security-aware name servers for the relevant zones. + +4.4 Configured Trust Anchors + + A security-aware resolver MUST be capable of being configured with at + + + +Arends, et al. Expires November 15, 2004 [Page 21] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + least one trusted public key or DS RR, and SHOULD be capable of being + configured with multiple trusted public keys or DS RRs. Since a + security-aware resolver will not be able to validate signatures + without such a configured trust anchor, the resolver SHOULD have some + reasonably robust mechanism for obtaining such keys when it boots; + examples of such a mechanism would be some form of non-volatile + storage (such as a disk drive) or some form of trusted local network + configuration mechanism. + + Note that trust anchors also covers key material that is updated in a + secure manner. This secure manner could be through physical media, a + key exchange protocol, or some other out of band means. + +4.5 Response Caching + + A security-aware resolver SHOULD cache each response as a single + atomic entry containing the entire answer, including the named RRset + and any associated DNSSEC RRs. The resolver SHOULD discard the + entire atomic entry when any of the RRs contained in it expire. In + most cases the appropriate cache index for the atomic entry will be + the triple , but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double . + +4.6 Handling of the CD and AD bits + + A security-aware resolver MAY set the CD bit in a query to one in + order to indicate that the resolver takes responsibility for + performing whatever authentication its local policy requires on the + RRsets in the response. See Section 3.2 for the effect this bit has + on the behavior of security-aware recursive name servers. + + A security-aware resolver MUST zero the AD bit when composing query + messages to protect against buggy name servers which blindly copy + header bits which they do not understand from the query message to + the response message. + + A resolver MUST disregard the meaning of the CD and AD bits in a + response unless the response was obtained using a secure channel or + the resolver was specifically configured to regard the message header + bits without using a secure channel. + +4.7 Caching BAD Data + + While many validation errors will be transient, some are likely to be + more persistent, such as those caused by administrative error + (failure to re-sign a zone, clock skew, and so forth). Since + requerying will not help in these cases, validating resolvers might + + + +Arends, et al. Expires November 15, 2004 [Page 22] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + generate a significant amount of unnecessary DNS traffic as a result + of repeated queries for RRsets with persistent validation failures. + + To prevent such unnecessary DNS traffic, security-aware resolvers MAY + cache data with invalid signatures, with some restrictions. + Conceptually, caching such data is similar to negative caching + [RFC2308], except that instead of caching a valid negative response, + the resolver is caching the fact that a particular answer failed to + validate. This document refers to a cache of data with invalid + signatures as a "BAD cache". + + Resolvers which implement a BAD cache MUST take steps to prevent the + cache from being useful as a denial-of-service attack amplifier. In + particular: + o Since RRsets which fail to validate do not have trustworthy TTLs, + the implementation MUST assign a TTL. This TTL SHOULD be small, + in order to mitigate the effect of caching the results of an + attack. + o In order to prevent caching of a transient validation failure + (which might be the result of an attack), resolvers SHOULD track + queries that result in validation failures, and SHOULD only answer + from the BAD cache after the number of times that responses to + queries for that particular have failed to + validate exceeds a threshold value. + + Resolvers MUST NOT return RRsets from the BAD cache unless the + resolver is not required to validate the signatures of the RRsets in + question under the rules given in Section 4.2 of this document. See + Section 3.2.2 for discussion of how the responses returned by a + security-aware recursive name server interact with a BAD cache. + +4.8 Synthesized CNAMEs + + A validating security-aware resolver MUST treat the signature of a + valid signed DNAME RR as also covering unsigned CNAME RRs which could + have been synthesized from the DNAME RR as described in [RFC2672], at + least to the extent of not rejecting a response message solely + because it contains such CNAME RRs. The resolver MAY retain such + CNAME RRs in its cache or in the answers it hands back, but is not + required to do so. + +4.9 Stub resolvers + + A security-aware stub resolver MUST support the DNSSEC RR types, at + least to the extent of not mishandling responses just because they + contain DNSSEC RRs. + + + + + +Arends, et al. Expires November 15, 2004 [Page 23] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +4.9.1 Handling of the DO Bit + + A non-validating security-aware stub resolver MAY include the DNSSEC + RRs returned by a security-aware recursive name server as part of the + data that the stub resolver hands back to the application which + invoked it but is not required to do so. A non-validating stub + resolver that wishes to do this will need to set the DO bit in + receive DNSSEC RRs from the recursive name server. + + A validating security-aware stub resolver MUST set the DO bit, since + otherwise it will not receive the DNSSEC RRs it needs to perform + signature validation. + +4.9.2 Handling of the CD Bit + + A non-validating security-aware stub resolver SHOULD NOT set the CD + bit when sending queries unless requested by the application layer, + since by definition, a non-validating stub resolver depends on the + security-aware recursive name server to perform validation on its + behalf. + + A validating security-aware stub resolver SHOULD set the CD bit, + since otherwise the security-aware recursive name server will answer + the query using the name server's local policy, which may prevent the + stub resolver from receiving data which would be acceptable to the + stub resolver's local policy. + +4.9.3 Handling of the AD Bit + + A non-validating security-aware stub resolver MAY chose to examine + the setting of the AD bit in response messages that it receives in + order to determine whether the security-aware recursive name server + which sent the response claims to have cryptographically verified the + data in the Answer and Authority sections of the response message. + Note, however, that the responses received by a security-aware stub + resolver are heavily dependent on the local policy of the + security-aware recursive name server, so as a practical matter there + may be little practical value to checking the status of the AD bit + except perhaps as a debugging aid. In any case, a security-aware + stub resolver MUST NOT place any reliance on signature validation + allegedly performed on its behalf except when the security-aware stub + resolver obtained the data in question from a trusted security-aware + recursive name server via a secure channel. + + A validating security-aware stub resolver SHOULD NOT examine the + setting of the AD bit in response messages, since, by definition, the + stub resolver performs its own signature validation regardless of the + setting of the AD bit. + + + +Arends, et al. Expires November 15, 2004 [Page 24] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +5. Authenticating DNS Responses + + In order to use DNSSEC RRs for authentication, a security-aware + resolver requires configured knowledge of at least one authenticated + DNSKEY or DS RR. The process for obtaining and authenticating this + initial trust anchors is achieved via some external mechanism. For + example, a resolver could use some off-line authenticated exchange to + obtain a zone's DNSKEY RR or obtain a DS RR that identifies and + authenticates a zone's DNSKEY RR. The remainder of this section + assumes that the resolver has somehow obtained an initial set of + trust anchors. + + An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY + RRset. To authenticate an apex DNSKEY RRset using an initial key, + the resolver MUST: + 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag + (DNSKEY RDATA bit 7) set to one. + 2. Verify that there is some RRSIG RR that covers the apex DNSKEY + RRset, and that the combination of the RRSIG RR and the initial + DNSKEY RR authenticates the DNSKEY RRset. The process for using + an RRSIG RR to authenticate an RRset is described in Section 5.3. + + Once the resolver has authenticated the apex DNSKEY RRset using an + initial DNSKEY RR, delegations from that zone can be authenticated + using DS RRs. This allows a resolver to start from an initial key, + and use DS RRsets to proceed recursively down the DNS tree obtaining + other apex DNSKEY RRsets. If the resolver were configured with a + root DNSKEY RR, and if every delegation had a DS RR associated with + it, then the resolver could obtain and validate any apex DNSKEY + RRset. The process of using DS RRs to authenticate referrals is + described in Section 5.2. + + Once the resolver has authenticated a zone's apex DNSKEY RRset, + Section 5.3 shows how the resolver can use DNSKEY RRs in the apex + DNSKEY RRset and RRSIG RRs from the zone to authenticate any other + RRsets in the zone. Section 5.4 shows how the resolver can use + authenticated NSEC RRsets from the zone to prove that an RRset is not + present in the zone. + + When a resolver indicates support for DNSSEC (by setting the DO bit), + a security-aware name server should attempt to provide the necessary + DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). + However, a security-aware resolver may still receive a response that + that lacks the appropriate DNSSEC RRs, whether due to configuration + issues such as an upstream security-oblivious recursive name server + that accidentally interferes with DNSSEC RRs or due to a deliberate + attack in which an adversary forges a response, strips DNSSEC RRs + + + +Arends, et al. Expires November 15, 2004 [Page 25] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + from a response, or modifies a query so that DNSSEC RRs appear not to + be requested. The absence of DNSSEC data in a response MUST NOT by + itself be taken as an indication that no authentication information + exists. + + A resolver SHOULD expect authentication information from signed + zones. A resolver SHOULD believe that a zone is signed if the + resolver has been configured with public key information for the + zone, or if the zone's parent is signed and the delegation from the + parent contains a DS RRset. + +5.1 Special Considerations for Islands of Security + + Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed + zones for which it is not possible to construct an authentication + chain to the zone from its parent. Validating signatures within an + island of security requires the validator to have some other means of + obtaining an initial authenticated zone key for the island. If a + validator cannot obtain such a key, it SHOULD switch to operating as + if the zones in the island of security are unsigned. + + All the normal processes for validating responses apply to islands of + security. The only difference between normal validation and + validation within an island of security is in how the validator + obtains a trust anchor for the authentication chain. + +5.2 Authenticating Referrals + + Once the apex DNSKEY RRset for a signed parent zone has been + authenticated, DS RRsets can be used to authenticate the delegation + to a signed child zone. A DS RR identifies a DNSKEY RR in the child + zone's apex DNSKEY RRset, and contains a cryptographic digest of the + child zone's DNSKEY RR. A strong cryptographic digest algorithm + ensures that an adversary can not easily generate a DNSKEY RR that + matches the digest. Thus, authenticating the digest allows a + resolver to authenticate the matching DNSKEY RR. The resolver can + then use this child DNSKEY RR to authenticate the entire child apex + DNSKEY RRset. + + Given a DS RR for a delegation, the child zone's apex DNSKEY RRset + can be authenticated if all of the following hold: + o The DS RR has been authenticated using some DNSKEY RR in the + parent's apex DNSKEY RRset (see Section 5.3); + o The Algorithm and Key Tag in the DS RR match the Algorithm field + and the key tag of a DNSKEY RR in the child zone's apex DNSKEY + RRset and, when hashed using the digest algorithm specified in the + DS RR's Digest Type field, results in a digest value that matches + the Digest field of the DS RR; and + + + +Arends, et al. Expires November 15, 2004 [Page 26] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + o The matching DNSKEY RR in the child zone has the Zone Flag bit set + to one, the corresponding private key has signed the child zone's + apex DNSKEY RRset, and the resulting RRSIG RR authenticates the + child zone's apex DNSKEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NSEC RRset proving that no DS + RRset exists for the delegated name (see Section 3.1.4). A + security-aware resolver MUST query the name servers for the parent + zone for the DS RRset if the referral includes neither a DS RRset nor + a NSEC RRset proving that the DS RRset does not exist (see Section + 4). + + If the validator authenticates an NSEC RRset that proves that no DS + RRset is present for this zone, then there is no authentication path + leading from the parent to the child. If the resolver has an initial + DNSKEY or DS RR that belongs to the child zone or to any delegation + below the child zone, this initial DNSKEY or DS RR MAY be used to + re-establish an authentication path. If no such initial DNSKEY or DS + RR exists, the validator can not authenticate RRsets in or below the + child zone. + + If the validator does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + Note that, for a signed delegation, there are two NSEC RRs associated + with the delegated name. One NSEC RR resides in the parent zone, and + can be used to prove whether a DS RRset exists for the delegated + name. The second NSEC RR resides in the child zone, and identifies + which RRsets are present at the apex of the child zone. The parent + NSEC RR and child NSEC RR can always be distinguished, since the SOA + bit will be set in the child NSEC RR and clear in the parent NSEC RR. + A security-aware resolver MUST use the parent NSEC RR when attempting + to prove that a DS RRset does not exist. + + If the resolver does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver will not be able to verify + the authentication path to the child zone. In this case, the + resolver SHOULD treat the child zone as if it were unsigned. + +5.3 Authenticating an RRset Using an RRSIG RR + + A validator can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The validator first checks the RRSIG + + + +Arends, et al. Expires November 15, 2004 [Page 27] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + RR to verify that it covers the RRset, has a valid time interval, and + identifies a valid DNSKEY RR. The validator then constructs the + canonical form of the signed data by appending the RRSIG RDATA + (excluding the Signature Field) with the canonical form of the + covered RRset. Finally, the validator uses the public key and + signature to authenticate the signed data. Section 5.3.1, Section + 5.3.2, and Section 5.3.3 describe each step in detail. + +5.3.1 Checking the RRSIG RR Validity + + A security-aware resolver can use an RRSIG RR to authenticate an + RRset if all of the following conditions hold: + o The RRSIG RR and the RRset MUST have the same owner name and the + same class; + o The RRSIG RR's Signer's Name field MUST be the name of the zone + that contains the RRset; + o The RRSIG RR's Type Covered field MUST equal the RRset's type; + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the RRSIG RR's Labels field; + o The validator's notion of the current time MUST be less than or + equal to the time listed in the RRSIG RR's Expiration field; + o The validator's notion of the current time MUST be greater than or + equal to the time listed in the RRSIG RR's Inception field; + o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST + match the owner name, algorithm, and key tag for some DNSKEY RR in + the zone's apex DNSKEY RRset; + o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY + RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) + set to one. + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the validator cannot predetermine which DNSKEY + RR to use to authenticate the signature, MUST try each matching + DNSKEY RR until either the signature is validated or the validator + has run out of matching public keys to try. + + Note that this authentication process is only meaningful if the + validator authenticates the DNSKEY RR before using it to validate + signatures. The matching DNSKEY RR is considered to be authentic if: + o The apex DNSKEY RRset containing the DNSKEY RR is considered + authentic; or + o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, + and the DNSKEY RR either matches an authenticated DS RR from the + parent zone or matches a trust anchor. + +5.3.2 Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + + + +Arends, et al. Expires November 15, 2004 [Page 28] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + Section 5.3.1, the validator needs to reconstruct the original signed + data. The original signed data includes RRSIG RDATA (excluding the + Signature field) and the canonical form of the RRset. Aside from + being ordered, the canonical form of the RRset might also differ from + the received RRset due to DNS name compression, decremented TTLs, or + wildcard expansion. The validator should use the following to + reconstruct the original signed data: + + signed_data = RRSIG_RDATA | RR(1) | RR(2)... where + + "|" denotes concatenation + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signature field excluded and the Signer's Name + in canonical form. + + RR(i) = name | type | class | OrigTTL | RDATA length | RDATA + + name is calculated according to the function below + + class is the RRset's class + + type is the RRset type and all RRs in the class + + OrigTTL is the value from the RRSIG Original TTL field + + All names in the RDATA field are in canonical form + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let rrsig_labels = the value of the RRSIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = Label count of the fqdn above. + + if rrsig_labels = fqdn_labels, + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the rightmost rrsig_label labels of the + fqdn + + if rrsig_labels > fqdn_labels + the RRSIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + + + +Arends, et al. Expires November 15, 2004 [Page 29] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + RRset. + + The canonical forms for names and RRsets are defined in + [I-D.ietf-dnsext-dnssec-records]. + + NSEC RRsets at a delegation boundary require special processing. + There are two distinct NSEC RRsets associated with a signed delegated + name. One NSEC RRset resides in the parent zone, and specifies which + RRset are present at the parent zone. The second NSEC RRset resides + at the child zone, and identifies which RRsets are present at the + apex in the child zone. The parent NSEC RRset and child NSEC RRset + can always be distinguished since only the child NSEC RRs will + specify an SOA RRset exists at the name. When reconstructing the + original NSEC RRset for the delegation from the parent zone, the NSEC + RRs MUST NOT be combined with NSEC RRs from the child zone, and when + reconstructing the original NSEC RRset for the apex of the child + zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent + zone. + + Note also that each of the two NSEC RRsets at a delegation point has + a corresponding RRSIG RR with an owner name matching the delegated + name, and each of these RRSIG RRs is authoritative data associated + with the same zone that contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + +5.3.3 Checking the Signature + + Once the resolver has validated the RRSIG RR as described in Section + 5.3.1 and reconstructed the original signed data as described in + Section 5.3.2, the validator can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the RRSIG RR identifies the cryptographic + algorithm used to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). + [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types + and provides pointers to the documents that define each algorithm's + use. + + Note that it is possible for more than one DNSKEY RR to match the + conditions in Section 5.3.1. In this case, the validator can only + determine which DNSKEY RR by trying each matching public key until + the validator either succeeds in validating the signature or runs out + of keys to try. + + + +Arends, et al. Expires November 15, 2004 [Page 30] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + If the Labels field of the RRSIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.3.4 describes how + to determine whether a wildcard was applied properly. + + If other RRSIG RRs also cover this RRset, the local resolver security + policy determines whether the resolver also needs to test these RRSIG + RRs, and determines how to resolve conflicts if these RRSIG RRs lead + to differing results. + + If the resolver accepts the RRset as authentic, the validator MUST + set the TTL of the RRSIG RR and each RR in the authenticated RRset to + a value no greater than the minimum of: + o The RRset's TTL as received in the response; + o The RRSIG RR's TTL as received in the response; + o The value in the RRSIG RR's Original TTL field; and + o The difference of the RRSIG RR's Signature Expiration time and the + current time. + +5.3.4 Authenticating A Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's owner name is greater than the + Labels field of the covering RRSIG RR, then the RRset and its + covering RRSIG RR were created as a result of wildcard expansion. + Once the validator has verified the signature as described in Section + 5.3, it must take additional steps to verify the non-existence of an + exact match or closer wildcard match for the query. Section 5.4 + discusses these steps. + + Note that the response received by the resolver should include all + NSEC RRs needed to authenticate the response (see Section 3.1.3). + +5.4 Authenticated Denial of Existence + + A resolver can use authenticated NSEC RRs to prove that an RRset is + not present in a signed zone. Security-aware name servers should + automatically include any necessary NSEC RRs for signed zones in + their responses to security-aware resolvers. + + Security-aware resolvers MUST first authenticate NSEC RRsets + according to the standard RRset authentication rules described in + Section 5.3, then apply the NSEC RRsets as follows: + o If the requested RR name matches the owner name of an + authenticated NSEC RR, then the NSEC RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + + + +Arends, et al. Expires November 15, 2004 [Page 31] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + type in the bit map. If the number of labels in an authenticated + NSEC RR's owner name equals the Labels field of the covering RRSIG + RR, then the existence of the NSEC RR proves that wildcard + expansion could not have been used to match the request. + o If the requested RR name would appear after an authenticated NSEC + RR's owner name and before the name listed in that NSEC RR's Next + Domain Name field according to the canonical DNS name order + defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with + the requested name exist in the zone. However, it is possible + that a wildcard could be used to match the requested RR owner name + and type, so proving that the requested RRset does not exist also + requires proving that no possible wildcard RRset exists that could + have been used to generate a positive response. + + To prove non-existence of an RRset, the resolver must be able to + verify both that the queried RRset does not exist and that no + relevant wildcard RRset exists. Proving this may require more than + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify non-existence of the requested RRset. As with all DNS + operations, however, the resolver MUST bound the work it puts into + answering any particular query. + + Since a validated NSEC RR proves the existence of both itself and its + corresponding RRSIG RR, a validator MUST ignore the settings of the + NSEC and RRSIG bits in an NSEC RR. + +5.5 Resolver Behavior When Signatures Do Not Validate + + If for whatever reason none of the RRSIGs can be validated, the + response SHOULD be considered BAD. If the validation was being done + to service a recursive query, the name server MUST return RCODE 2 to + the originating client. However, it MUST return the full response if + and only if the original query had the CD bit set. See also Section + 4.7 on caching responses that do not validate. + +5.6 Authentication Example + + Appendix C shows an example the authentication process. + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 32] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +6. IANA Considerations + + [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA + considerations introduced by DNSSEC. The additional IANA + considerations discussed in this document: + + [RFC2535] reserved the CD and AD bits in the message header. The + meaning of the AD bit was redefined in [RFC3655] and the meaning of + both the CD and AD bit are restated in this document. No new bits in + the DNS message header are defined in this document. + + [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit + and defined its use. The use is restated but not altered in this + document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 33] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general + security considerations related to DNSSEC; see + [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the + DNSSEC resource record types. + + An active attacker who can set the CD bit in a DNS query message or + the AD bit in a DNS response message can use these bits to defeat the + protection which DNSSEC attempts to provide to security-oblivious + recursive-mode resolvers. For this reason, use of these control bits + by a security-aware recursive-mode resolver requires a secure + channel. See Section 3.2.2 and Section 4.9 for further discussion. + + The protocol described in this document attempts to extend the + benefits of DNSSEC to security-oblivious stub resolvers. However, + since recovery from validation failures is likely to be specific to + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will need to pay close attention to the + behavior of the applications which use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidentally denying service to the clients it + is intended to support. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 34] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +8. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 35] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +9. References + +9.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-10 (work in progress), May + 2004. + + [I-D.ietf-dnsext-dnssec-records] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Resource Records for DNS Security Extensions", + draft-ietf-dnsext-dnssec-records-08 (work in progress), + May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + +9.2 Informative References + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "KEY RR Secure Entry Point Flag", + draft-ietf-dnsext-nsec-rdata-05 (work in progress), March + + + +Arends, et al. Expires November 15, 2004 [Page 36] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + 2004. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + +Arends, et al. Expires November 15, 2004 [Page 37] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 38] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB + 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE + VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO + 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM + W6OISukd1EQt7a0kygkg+PEDxdI= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + 3600 DNSKEY 256 3 5 ( + AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV + rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e + k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo + vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI + + + +Arends, et al. Expires November 15, 2004 [Page 39] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== + ) + 3600 DNSKEY 257 3 5 ( + AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl + LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ + syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP + RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT + Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== + ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 9465 example. + ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ + xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ + XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 + hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY + NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z + DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri + bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp + eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk + 7z5OXogYVaFzHKillDt3HRxHIZM= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba + U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 + 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I + BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g + sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + + + +Arends, et al. Expires November 15, 2004 [Page 40] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l + e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh + ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 + AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw + FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG + CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p + P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN + 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL + AhS+JOVfDI/79QtyTI0SaDWcg8U= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + ns1.example. 3600 IN A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + + + +Arends, et al. Expires November 15, 2004 [Page 41] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE + VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb + 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH + l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw + Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + + + +Arends, et al. Expires November 15, 2004 [Page 42] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK + vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E + mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI + NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e + IjgiM8PXkBQtxPq37wDKALkyn7Q= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia + t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj + q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq + GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb + +gLcMZBnHJ326nb/TOOmrqNmQQE= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 + t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq + BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 + 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ + RgNvuwbioFSEuv2pNlkq0goYxNY= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + + + +Arends, et al. Expires November 15, 2004 [Page 43] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY + 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k + mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi + asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W + GghLahumFIpg4MO3LS/prgzVVWo= ) + + The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA + Flags indicate that each of these DNSKEY RRs is a zone key. One of + these DNSKEY RRs also has the SEP flag set and has been used to sign + the apex DNSKEY RRset; this is the key which should be hashed to + generate a DS record to be inserted into the parent zone. The other + DNSKEY is used to sign all the other RRsets in the zone. + + The zone includes a wildcard entry "*.w.example". Note that the name + "*.w.example" is used in constructing NSEC chains, and that the RRSIG + covering the "*.w.example" MX RRset has a label count of 2. + + The zone also includes two delegations. The delegation to + "b.example" includes an NS RRset, glue address records, and an NSEC + RR; note that only the NSEC RRset is signed. The delegation to + "a.example" provides a DS RR; note that only the NSEC and DS RRsets + are signed. + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 44] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1 Answer + + A successful query to an authoritative server. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + + + +Arends, et al. Expires November 15, 2004 [Page 45] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + + +B.2 Name Error + + An authoritative name error. The NSEC RRs prove that the name does + not exist and that no covering wildcard exists. + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + ml.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + + + +Arends, et al. Expires November 15, 2004 [Page 46] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + +B.3 No Data Error + + A "NODATA" response. The NSEC RR proves that the name exists and + that the requested RR type does not. + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 47] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + + ;; Additional + ;; (empty) + + +B.4 Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 48] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + + +B.5 Referral to Unsigned Zone + + Referral to an unsigned zone. The NSEC RR proves that no DS RR for + this delegation exists in the parent zone. + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 49] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + + +B.6 Wildcard Expansion + + A successful query which was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC RR proves that no + closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + + ;; Authority + + + +Arends, et al. Expires November 15, 2004 [Page 50] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + + +B.7 Wildcard No Data Error + + A "NODATA" response for a name covered by a wildcard. The NSEC RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + + + +Arends, et al. Expires November 15, 2004 [Page 51] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + + ;; Additional + ;; (empty) + + +B.8 DS Child Zone No Data Error + + A "NODATA" response for a QTYPE=DS query which was mistakenly sent to + a name server for the child zone. + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 52] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 53] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +Appendix C. Authentication Examples + + The examples in this section show how the response messages in + Appendix B are authenticated. + +C.1 Authenticating An Answer + + The query in section Appendix B.1 returned an MX RRset for + "x.w.example.com". The corresponding RRSIG indicates the MX RRset + was signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The resolver needs the corresponding DNSKEY RR in order to + authenticate this answer. The discussion below describes how a + resolver might obtain this DNSKEY RR. + + The RRSIG indicates the original TTL of the MX RRset was 3600 and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 3 indicates the answer was not + the result of wildcard expansion. The "x.w.example.com" MX RRset is + placed in canonical form and, assuming the current time falls between + the signature inception and expiration dates, the signature is + authenticated. + +C.1.1 Authenticating the example DNSKEY RR + + This example shows the logical authentication process that starts + from the a configured root DNSKEY (or DS RR) and moves down the tree + to authenticate the desired "example" DNSKEY RR. Note the logical + order is presented for clarity and an implementation may choose to + construct the authentication as referrals are received or may choose + to construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with an configured DNSKEY RR for the + root zone (or a configured DS RR for the root zone). The resolver + checks this configured DNSKEY RR is present in the root DNSKEY RRset + (or the DS RR matches some DNSKEY in the root DNSKEY RRset), this + DNSKEY RR has signed the root DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the DNSKEY + RRset are considered authenticated. The resolver then uses one (or + more) of the root DNSKEY RRs to authenticate the "example" DS RRset. + Note the resolver may need to query the root zone to obtain the root + DNSKEY RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + + + +Arends, et al. Expires November 15, 2004 [Page 54] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + matching "example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the "example" + DNSKEY RRset are considered authenticated. + + Finally the resolver checks that some DNSKEY RR in the "example" + DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This DNSKEY + is used to authenticated the RRSIG included in the response. If + multiple "example" DNSKEY RRs match this algorithm and key tag, then + each DNSKEY RR is tried and the answer is authenticated if any of the + matching DNSKEY RRs validates the signature as described above. + +C.2 Name Error + + The query in section Appendix B.2 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + authenticated in a manner identical to that of the MX RRset discussed + above. + +C.3 No Data Error + + The query in section Appendix B.3 returned an NSEC RR that proves the + requested name exists, but the requested RR type does not exist. The + negative reply is authenticated by verifying the NSEC RR. The NSEC + RR is authenticated in a manner identical to that of the MX RRset + discussed above. + +C.4 Referral to Signed Zone + + The query in section Appendix B.4 returned a referral to the signed + "a.example." zone. The DS RR is authenticated in a manner identical + to that of the MX RRset discussed above. This DS RR is used to + authenticate the "a.example" DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks this DNSKEY + RR has signed the "a.example" DNSKEY RRset and the signature lifetime + is valid. If all these conditions are met, all keys in the + "a.example" DNSKEY RRset are considered authenticated. + +C.5 Referral to Unsigned Zone + + The query in section Appendix B.5 returned a referral to an unsigned + "b.example." zone. The NSEC proves that no authentication leads from + "example" to "b.example" and the NSEC RR is authenticated in a manner + + + +Arends, et al. Expires November 15, 2004 [Page 55] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + identical to that of the MX RRset discussed above. + +C.6 Wildcard Expansion + + The query in section Appendix B.6 returned an answer that was + produced as a result of wildcard expansion. The RRset expanded as the + similar to The corresponding RRSIG indicates the MX RRset was signed + by an "example" DNSKEY with algorithm 5 and key tag 38519. The RRSIG + indicates the original TTL of the MX RRset was 3600 and, for the + purpose of authentication, the current TTL is replaced by 3600. The + RRSIG labels field value of 2 indicates the answer the result of + wildcard expansion since the "a.z.w.example" name contains 4 labels. + The name "a.z.w.w.example" is replaced by "*.w.example", the MX RRset + is placed in canonical form and, assuming the current time falls + between the signature inception and expiration dates, the signature + is authenticated. + + The NSEC proves that no closer match (exact or closer wildcard) could + have been used to answer this query and the NSEC RR must also be + authenticated before the answer is considered valid. + +C.7 Wildcard No Data Error + + The query in section Appendix B.7 returned NSEC RRs that prove the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. + +C.8 DS Child Zone No Data Error + + The query in section Appendix B.8 returned NSEC RRs that shows the + requested was answered by a child server ("example" server). The + NSEC RR indicates the presence of an SOA RR, showing the answer is + from the child . Queries for the "example" DS RRset should be sent + to the parent servers ("root" servers). + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 56] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires November 15, 2004 [Page 57] + +Internet-Draft DNSSEC Protocol Modifications May 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 58] + + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt new file mode 100644 index 0000000000..3ca99bfb72 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-08.txt @@ -0,0 +1,1961 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: November 15, 2004 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + May 17, 2004 + + + Resource Records for the DNS Security Extensions + draft-ietf-dnsext-dnssec-records-08 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 15, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document is part of a family of documents that describes the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of resource records and protocol modifications that + provide source authentication for the DNS. This document defines the + public key (DNSKEY), delegation signer (DS), resource record digital + + + +Arends, et al. Expires November 15, 2004 [Page 1] + +Internet-Draft DNSSEC Resource Records May 2004 + + + signature (RRSIG), and authenticated denial of existence (NSEC) + resource records. The purpose and format of each resource record is + described in detail, and an example of each resource record is given. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1 Background and Related Documents . . . . . . . . . . . . . 4 + 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . 4 + 1.3.1 Technical Changes or Corrections . . . . . . . . . . . 4 + 1.3.2 Typos and Minor Corrections . . . . . . . . . . . . . 5 + 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . . 6 + 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . 6 + 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . 6 + 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . 7 + 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . 7 + 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . 7 + 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . 7 + 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . 7 + 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . 8 + 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . . 9 + 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . 9 + 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . 10 + 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . 10 + 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . 10 + 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . 11 + 3.1.5 Signature Expiration and Inception Fields . . . . . . 11 + 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . 11 + 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . 12 + 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . 12 + 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . 13 + 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 13 + 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . . 15 + 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . 15 + 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . 15 + 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . 16 + 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . 17 + 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . 17 + 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . 17 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . . 19 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 19 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . 20 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . 20 + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . 20 + + + +Arends, et al. Expires November 15, 2004 [Page 2] + +Internet-Draft DNSSEC Resource Records May 2004 + + + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . 20 + 5.2 Processing of DS RRs When Validating Responses . . . . . . 20 + 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . 21 + 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . 21 + 6. Canonical Form and Order of Resource Records . . . . . . . . . 22 + 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . 22 + 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . 22 + 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . 23 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 + 10.2 Informative References . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 + A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . . 30 + A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . 30 + A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . 30 + A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . 31 + B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . . 32 + B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . 33 + Intellectual Property and Copyright Statements . . . . . . . . 34 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 3] + +Internet-Draft DNSSEC Resource Records May 2004 + + +1. Introduction + + The DNS Security Extensions (DNSSEC) introduce four new DNS resource + record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the + purpose of each resource record (RR), the RR's RDATA format, and its + presentation format (ASCII representation). + +1.1 Background and Related Documents + + The reader is assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035] and subsequent RFCs that update + them: [RFC2136], [RFC2181] and [RFC2308]. + + This document is part of a family of documents that define the DNS + security extensions. The DNS security extensions (DNSSEC) are a + collection of resource records and DNS protocol modifications that + add source authentication and data integrity to the Domain Name + System (DNS). An introduction to DNSSEC and definitions of common + terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description + of DNS protocol modifications can be found in + [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC + resource records. + +1.2 Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.3 Editors' Notes + +1.3.1 Technical Changes or Corrections + + Please report technical corrections to dnssec-editors@east.isi.edu. + To assist the editors, please indicate the text in error and point + out the RFC that defines the correct behavior. For a technical + change where no RFC that defines the correct behavior, or if there's + more than one applicable RFC and the definitions conflict, please + post the issue to namedroppers. + + An example correction to dnssec-editors might be: Page X says + "DNSSEC RRs SHOULD be automatically returned in responses." This was + true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the + DNSSEC RR types MUST NOT be included in responses unless the resolver + indicated support for DNSSEC. + + + + + + +Arends, et al. Expires November 15, 2004 [Page 4] + +Internet-Draft DNSSEC Resource Records May 2004 + + +1.3.2 Typos and Minor Corrections + + Please report any typos corrections to dnssec-editors@east.isi.edu. + To assist the editors, please provide enough context for us to find + the incorrect text quickly. + + An example message to dnssec-editors might be: page X says "the + DNSSEC standard has been in development for over 1 years". It + should read "over 10 years". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 5] + +Internet-Draft DNSSEC Resource Records May 2004 + + +2. The DNSKEY Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). The public keys are stored in DNSKEY + resource records and are used in the DNSSEC authentication process + described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its + authoritative RRsets using a private key and stores the corresponding + public key in a DNSKEY RR. A resolver can then use the public key to + authenticate signatures covering the RRsets in the zone. + + The DNSKEY RR is not intended as a record for storing arbitrary + public keys and MUST NOT be used to store certificates or public keys + that do not directly relate to the DNS infrastructure. + + The Type value for the DNSKEY RR type is 48. + + The DNSKEY RR is class independent. + + The DNSKEY RR has no special TTL requirements. + +2.1 DNSKEY RDATA Wire Format + + The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 + octet Protocol Field, a 1 octet Algorithm Field, and the Public Key + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Protocol | Algorithm | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Public Key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Flags Field + + Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, + then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner + name MUST be the name of a zone. If bit 7 has value 0, then the + DNSKEY record holds some other type of DNS public key, such as a + public key used by TKEY and MUST NOT be used to verify RRSIGs that + cover RRsets. + + Bit 15 of the Flags field is the Secure Entry Point flag, described + in [RFC3757]. If bit 15 has value 1, then the DNSKEY record holds a + + + +Arends, et al. Expires November 15, 2004 [Page 6] + +Internet-Draft DNSSEC Resource Records May 2004 + + + key intended for use as a secure entry point. This flag is only + intended to be to a hint to zone signing or debugging software as to + the intended use of this DNSKEY record; validators MUST NOT alter + their behavior during the signature validation process in any way + based on the setting of this bit. This also means a DNSKEY RR with + the SEP bit set would also need the Zone Key flag set in order to + legally be able to generate signatures. A DNSKEY RR with the SEP set + and the Zone Key flag not set is an invalid DNSKEY. + + Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon + creation of the DNSKEY RR, and MUST be ignored upon reception. + +2.1.2 The Protocol Field + + The Protocol Field MUST have value 3 and the DNSKEY RR MUST be + treated as invalid during signature verification if found to be some + value other than 3. + +2.1.3 The Algorithm Field + + The Algorithm field identifies the public key's cryptographic + algorithm and determines the format of the Public Key field. A list + of DNSSEC algorithm types can be found in Appendix A.1 + +2.1.4 The Public Key Field + + The Public Key Field holds the public key material. The format + depends on the algorithm of the key being stored and are described in + separate documents. + +2.1.5 Notes on DNSKEY RDATA Design + + Although the Protocol Field always has value 3, it is retained for + backward compatibility with early versions of the KEY record. + +2.2 The DNSKEY RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Flag field MUST be represented as an unsigned decimal integer + with a value of 0, 256, or 257. + + The Protocol Field MUST be represented as an unsigned decimal integer + with a value of 3. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic as specified in Appendix A.1. + + + + +Arends, et al. Expires November 15, 2004 [Page 7] + +Internet-Draft DNSSEC Resource Records May 2004 + + + The Public Key field MUST be represented as a Base64 encoding of the + Public Key. Whitespace is allowed within the Base64 text. For a + definition of Base64 encoding, see [RFC1521] Section 5.2. + +2.3 DNSKEY RR Example + + The following DNSKEY RR stores a DNS zone key for example.com. + + example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 + Cbl+BBZH4b/0PY1kxkmvHjcZc8no + kfzj31GajIQKY+5CptLr3buXA10h + WqTkF7H6RfoRqXQeogmMHfpftf6z + Mv1LyBUgia7za6ZEzOJBOztyvhjL + 742iU/TpPSEDhm2SNKLijfUppn1U + aNvv4w== ) + + The first four text fields specify the owner name, TTL, Class, and RR + type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in + the Flags field has value 1. Value 3 is the fixed Protocol value. + Value 5 indicates the public key algorithm. Appendix A.1 identifies + algorithm type 5 as RSA/SHA1 and indicates that the format of the + RSA/SHA1 public key field is defined in [RFC3110]. The remaining + text is a Base64 encoding of the public key. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 8] + +Internet-Draft DNSSEC Resource Records May 2004 + + +3. The RRSIG Resource Record + + DNSSEC uses public key cryptography to sign and authenticate DNS + resource record sets (RRsets). Digital signatures are stored in + RRSIG resource records and are used in the DNSSEC authentication + process described in [I-D.ietf-dnsext-dnssec-protocol]. A validator + can use these RRSIG RRs to authenticate RRsets from the zone. The + RRSIG RR MUST only be used to carry verification material (digital + signatures) used to secure DNS operations. + + An RRSIG record contains the signature for an RRset with a particular + name, class, and type. The RRSIG RR specifies a validity interval + for the signature and uses the Algorithm, the Signer's Name, and the + Key Tag to identify the DNSKEY RR containing the public key that a + validator can use to verify the signature. + + Because every authoritative RRset in a zone must be protected by a + digital signature, RRSIG RRs must be present for names containing a + CNAME RR. This is a change to the traditional DNS specification + [RFC1034] that stated that if a CNAME is present for a name, it is + the only type allowed at that name. A RRSIG and NSEC (see Section 4) + MUST exist for the same name as a CNAME resource record in a signed + zone. + + The Type value for the RRSIG RR type is 46. + + The RRSIG RR is class independent. + + An RRSIG RR MUST have the same class as the RRset it covers. + + The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset + it covers. This is an exception to the [RFC2181] rules for TTL + values of individual RRs within a RRset: individual RRSIG with the + same owner name will have different TTL values if the RRsets they + cover have different TTL values. + +3.1 RRSIG RDATA Wire Format + + The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a + 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original + TTL field, a 4 octet Signature Expiration field, a 4 octet Signature + Inception field, a 2 octet Key tag, the Signer's Name field, and the + Signature field. + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 9] + +Internet-Draft DNSSEC Resource Records May 2004 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signature Inception | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Signature / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1.1 The Type Covered Field + + The Type Covered field identifies the type of the RRset that is + covered by this RRSIG record. + +3.1.2 The Algorithm Number Field + + The Algorithm Number field identifies the cryptographic algorithm + used to create the signature. A list of DNSSEC algorithm types can + be found in Appendix A.1 + +3.1.3 The Labels Field + + The Labels field specifies the number of labels in the original RRSIG + RR owner name. The significance of this field is that a validator + uses it to determine if the answer was synthesized from a wildcard. + If so, it can be used to determine what owner name was used in + generating the signature. + + To validate a signature, the validator needs the original owner name + that was used to create the signature. If the original owner name + contains a wildcard label ("*"), the owner name may have been + expanded by the server during the response process, in which case the + validator will need to reconstruct the original owner name in order + to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] + describes how to use the Labels field to reconstruct the original + owner name. + + + +Arends, et al. Expires November 15, 2004 [Page 10] + +Internet-Draft DNSSEC Resource Records May 2004 + + + The value of the Labels field MUST NOT count either the null (root) + label that terminates the owner name or the wildcard label (if + present). The value of the Labels field MUST be less than or equal + to the number of labels in the RRSIG owner name. For example, + "www.example.com." has a Labels field value of 3, and + "*.example.com." has a Labels field value of 2. Root (".") has a + Labels field value of 0. + + Although the wildcard label is not included in the count stored in + the Labels field of the RRSIG RR, the wildcard label is part of the + RRset's owner name when generating or verifying the signature. + +3.1.4 Original TTL Field + + The Original TTL field specifies the TTL of the covered RRset as it + appears in the authoritative zone. + + The Original TTL field is necessary because a caching resolver + decrements the TTL value of a cached RRset. In order to validate a + signature, a validator requires the original TTL. + [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original + TTL field value to reconstruct the original TTL. + +3.1.5 Signature Expiration and Inception Fields + + The Signature Expiration and Inception fields specify a validity + period for the signature. The RRSIG record MUST NOT be used for + authentication prior to the inception date and MUST NOT be used for + authentication after the expiration date. + + Signature Expiration and Inception field values are in POSIX.1 time + format: a 32-bit unsigned number of seconds elapsed since 1 January + 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The + longest interval which can be expressed by this format without + wrapping is approximately 136 years. An RRSIG RR can have an + Expiration field value which is numerically smaller than the + Inception field value if the expiration field value is near the + 32-bit wrap-around point or if the signature is long lived. Because + of this, all comparisons involving these fields MUST use "Serial + number arithmetic" as defined in [RFC1982]. As a direct consequence, + the values contained in these fields cannot refer to dates more than + 68 years in either the past or the future. + +3.1.6 The Key Tag Field + + The Key Tag field contains the key tag value of the DNSKEY RR that + validates this signature. Appendix B explains how to calculate Key + Tag values. + + + +Arends, et al. Expires November 15, 2004 [Page 11] + +Internet-Draft DNSSEC Resource Records May 2004 + + +3.1.7 The Signer's Name Field + + The Signer's Name field value identifies the owner name of the DNSKEY + RR which a validator should use to validate this signature. The + Signer's Name field MUST contain the name of the zone of the covered + RRset. A sender MUST NOT use DNS name compression on the Signer's + Name field when transmitting a RRSIG RR. + +3.1.8 The Signature Field + + The Signature field contains the cryptographic signature that covers + the RRSIG RDATA (excluding the Signature field) and the RRset + specified by the RRSIG owner name, RRSIG class, and RRSIG Type + Covered field. The format of this field depends on the algorithm in + use and these formats are described in separate companion documents. + +3.1.8.1 Signature Calculation + + A signature covers the RRSIG RDATA (excluding the Signature Field) + and covers the data RRset specified by the RRSIG owner name, RRSIG + class, and RRSIG Type Covered fields. The RRset is in canonical form + (see Section 6) and the set RR(1),...RR(n) is signed as follows: + + signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where + + "|" denotes concatenation; + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signer's Name field in canonical form and + the Signature field excluded; + + RR(i) = owner | type | class | TTL | RDATA length | RDATA + + "owner" is the fully qualified owner name of the RRset in + canonical form (for RRs with wildcard owner names, the + wildcard label is included in the owner name); + + Each RR MUST have the same owner name as the RRSIG RR; + + Each RR MUST have the same class as the RRSIG RR; + + Each RR in the RRset MUST have the RR type listed in the + RRSIG RR's Type Covered field; + + Each RR in the RRset MUST have the TTL listed in the + RRSIG Original TTL Field; + + Any DNS names in the RDATA field of each RR MUST be in + + + +Arends, et al. Expires November 15, 2004 [Page 12] + +Internet-Draft DNSSEC Resource Records May 2004 + + + canonical form; and + + The RRset MUST be sorted in canonical order. + + See Section 6.1 and Section 6.2 for details on canonical name order + and canonical RR form. + +3.2 The RRSIG RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Type Covered field is represented as a RR type mnemonic. When + the mnemonic is not known, the TYPE representation as described in + [RFC3597] (section 5) MUST be used. + + The Algorithm field value MUST be represented either as an unsigned + decimal integer or as an algorithm mnemonic as specified in Appendix + A.1. + + The Labels field value MUST be represented as an unsigned decimal + integer. + + The Original TTL field value MUST be represented as an unsigned + decimal integer. + + The Signature Expiration Time and Inception Time field values MUST be + represented either as seconds since 1 January 1970 00:00:00 UTC or in + the form YYYYMMDDHHmmSS in UTC, where: + YYYY is the year (0000-9999, but see Section 3.1.5); + 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); + mm is the minute (00-59); and + SS is the second (00-59). + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Signer's Name field value MUST be represented as a domain name. + + The Signature field is represented as a Base64 encoding of the + signature. Whitespace is allowed within the Base64 text. See + Section 2.2. + +3.3 RRSIG RR Example + + The following RRSIG RR stores the signature for the A RRset of + host.example.com: + + + + +Arends, et al. Expires November 15, 2004 [Page 13] + +Internet-Draft DNSSEC Resource Records May 2004 + + + host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( + 20030220173103 2642 example.com. + oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr + PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o + B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t + GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG + J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) + + The first four fields specify the owner name, TTL, Class, and RR type + (RRSIG). The "A" represents the Type Covered field. The value 5 + identifies the algorithm used (RSA/SHA1) to create the signature. + The value 3 is the number of Labels in the original owner name. The + value 86400 in the RRSIG RDATA is the Original TTL for the covered A + RRset. 20030322173103 and 20030220173103 are the expiration and + inception dates, respectively. 2642 is the Key Tag, and example.com. + is the Signer's Name. The remaining text is a Base64 encoding of the + signature. + + Note that combination of RRSIG RR owner name, class, and Type Covered + indicate that this RRSIG covers the "host.example.com" A RRset. The + Label value of 3 indicates that no wildcard expansion was used. The + Algorithm, Signer's Name, and Key Tag indicate this signature can be + authenticated using an example.com zone DNSKEY RR whose algorithm is + 5 and key tag is 2642. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 14] + +Internet-Draft DNSSEC Resource Records May 2004 + + +4. The NSEC Resource Record + + The NSEC resource record lists two separate things: the owner name of + the next authoritative RRset in the canonical ordering of the zone, + and the set of RR types present at the NSEC RR's owner name. The + complete set of NSEC RRs in a zone both indicate which authoritative + RRsets exist in a zone and also form a chain of authoritative owner + names in the zone. This information is used to provide authenticated + denial of existence for DNS data, as described in + [I-D.ietf-dnsext-dnssec-protocol]. + + Because every authoritative name in a zone must be part of the NSEC + chain, NSEC RRs must be present for names containing a CNAME RR. + This is a change to the traditional DNS specification [RFC1034] that + stated that if a CNAME is present for a name, it is the only type + allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist + for the same name as a CNAME resource record in a signed zone. + + See [I-D.ietf-dnsext-dnssec-protocol] for discussion of how a zone + signer determines precisely which NSEC RRs it needs to include in a + zone. + + The type value for the NSEC RR is 47. + + The NSEC RR is class independent. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [RFC2308]. + +4.1 NSEC RDATA Wire Format + + The RDATA of the NSEC RR is as shown below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Type Bit Maps / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +4.1.1 The Next Domain Name Field + + The Next Domain Name field contains the owner name of the next + authoritative owner name in the canonical ordering of the zone; see + Section 6.1 for an explanation of canonical ordering. The value of + the Next Domain Name field in the last NSEC record in the zone is the + + + +Arends, et al. Expires November 15, 2004 [Page 15] + +Internet-Draft DNSSEC Resource Records May 2004 + + + name of the zone apex (the owner name of the zone's SOA RR). + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. + + Owner names of RRsets not authoritative for the given zone (such as + glue records) MUST NOT be listed in the Next Domain Name unless at + least one authoritative RRset exists at the same owner name. + +4.1.2 The Type Bit Maps Field + + The Type Bit Maps field identifies the RRset types which exist at the + NSEC RR's owner name. + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that has + at least one active RR type is encoded using a single octet window + number (from 0 to 255), a single octet bitmap length (from 1 to 32) + indicating the number of octets used for the window block's bitmap, + and up to 32 octets (256 bits) of bitmap. + + Blocks are present in the NSEC RR RDATA in increasing numerical + order. + + Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ + + where "|" denotes concatenation. + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRset of that type is present for the NSEC + RR's owner name. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC RR's owner name. + + Bits representing pseudo-types MUST be set to 0, since they do not + appear in zone data. If encountered, they MUST be ignored upon + reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + interpreted as zero octets. + + + + +Arends, et al. Expires November 15, 2004 [Page 16] + +Internet-Draft DNSSEC Resource Records May 2004 + + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and the RR + types for which the parent zone has authoritative data MUST be set to + 1; bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be set to 0. + + A zone MUST NOT include an NSEC RR for any domain name that only + holds glue records. + +4.1.3 Inclusion of Wildcard Names in NSEC RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for purposes of generating NSEC RRs. Wildcard owner names + appear in the Next Domain Name field without any wildcard expansion. + [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards + on authenticated denial of existence. + +4.2 The NSEC RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The Type Bit Maps field is represented as a sequence of RR type + mnemonics. When the mnemonic is not known, the TYPE representation + as described in [RFC3597] (section 5) MUST be used. + +4.3 NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and identifies the next authoritative name after + alfa.example.com. + + alfa.example.com. 86400 IN NSEC host.example.com. ( + A MX RRSIG NSEC TYPE1234 ) + + The first four text fields specify the name, TTL, Class, and RR type + (NSEC). The entry host.example.com. is the next authoritative name + after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, + and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and + TYPE1234 RRsets associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 17] + +Internet-Draft DNSSEC Resource Records May 2004 + + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x20 + + Assuming that the validator can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or could + be used to prove there is no AAAA record associated with + alfa.example.com. Authenticated denial of existence is discussed in + [I-D.ietf-dnsext-dnssec-protocol]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 18] + +Internet-Draft DNSSEC Resource Records May 2004 + + +5. The DS Resource Record + + The DS Resource Record refers to a DNSKEY RR and is used in the DNS + DNSKEY authentication process. A DS RR refers to a DNSKEY RR by + storing the key tag, algorithm number, and a digest of the DNSKEY RR. + Note that while the digest should be sufficient to identify the + public key, storing the key tag and key algorithm helps make the + identification process more efficient. By authenticating the DS + record, a resolver can authenticate the DNSKEY RR to which the DS + record points. The key authentication process is described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The DS RR and its corresponding DNSKEY RR have the same owner name, + but they are stored in different locations. The DS RR appears only + on the upper (parental) side of a delegation, and is authoritative + data in the parent zone. For example, the DS RR for "example.com" is + stored in the "com" zone (the parent zone) rather than in the + "example.com" zone (the child zone). The corresponding DNSKEY RR is + stored in the "example.com" zone (the child zone). This simplifies + DNS zone management and zone signing, but introduces special response + processing requirements for the DS RR; these are described in + [I-D.ietf-dnsext-dnssec-protocol]. + + The type number for the DS record is 43. + + The DS resource record is class independent. + + The DS RR has no special TTL requirements. + +5.1 DS RDATA Wire Format + + The RDATA for a DS RR consists of a 2 octet Key Tag field, a one + octet Algorithm field, a one octet Digest Type field, and a Digest + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key Tag | Algorithm | Digest Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / / + / Digest / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 19] + +Internet-Draft DNSSEC Resource Records May 2004 + + +5.1.1 The Key Tag Field + + The Key Tag field lists the key tag of the DNSKEY RR referred to by + the DS record. + + The Key Tag used by the DS RR is identical to the Key Tag used by + RRSIG RRs. Appendix B describes how to compute a Key Tag. + +5.1.2 The Algorithm Field + + The Algorithm field lists the algorithm number of the DNSKEY RR + referred to by the DS record. + + The algorithm number used by the DS RR is identical to the algorithm + number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm + number types. + +5.1.3 The Digest Type Field + + The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY + RR. The Digest Type field identifies the algorithm used to construct + the digest. Appendix A.2 lists the possible digest algorithm types. + +5.1.4 The Digest Field + + The DS record refers to a DNSKEY RR by including a digest of that + DNSKEY RR. + + The digest is calculated by concatenating the canonical form of the + fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, + and then applying the digest algorithm. + + digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); + + "|" denotes concatenation + + DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. + + + The size of the digest may vary depending on the digest algorithm and + DNSKEY RR size. As of the time of writing, the only defined digest + algorithm is SHA-1, which produces a 20 octet digest. + +5.2 Processing of DS RRs When Validating Responses + + The DS RR links the authentication chain across zone boundaries, so + the DS RR requires extra care in processing. The DNSKEY RR referred + to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST + + + +Arends, et al. Expires November 15, 2004 [Page 20] + +Internet-Draft DNSSEC Resource Records May 2004 + + + have Flags bit 7 set to value 1. If the DNSKEY flags do not indicate + a DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT + be used in the validation process. + +5.3 The DS RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Key Tag field MUST be represented as an unsigned decimal integer. + + The Algorithm field MUST be represented either as an unsigned decimal + integer or as an algorithm mnemonic specified in Appendix A.1. + + The Digest Type field MUST be represented as an unsigned decimal + integer. + + The Digest MUST be represented as a sequence of case-insensitive + hexadecimal digits. Whitespace is allowed within the hexadecimal + text. + +5.4 DS RR Example + + The following example shows a DNSKEY RR and its corresponding DS RR. + + dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz + fwJr1AYtsmx3TGkJaNXVbfi/ + 2pHm822aJ5iI9BMzNXxeYCmZ + DRD99WYwYqUSdjMmmAphXdvx + egXd/M5+X7OrzKBaMbCVdFLU + Uh6DhweJBjEVv5f2wwjM9Xzc + nOf+EPbtG9DMBmADjFDc2w/r + ljwvFw== + ) ; key id = 60485 + + dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A + 98631FAD1A292118 ) + + + The first four text fields specify the name, TTL, Class, and RR type + (DS). Value 60485 is the key tag for the corresponding + "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm + used by this "dskey.example.com." DNSKEY RR. The value 1 is the + algorithm used to construct the digest, and the rest of the RDATA + text is the digest in hexadecimal. + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 21] + +Internet-Draft DNSSEC Resource Records May 2004 + + +6. Canonical Form and Order of Resource Records + + This section defines a canonical form for resource records, a + canonical ordering of DNS names, and a canonical ordering of resource + records within an RRset. A canonical name order is required to + construct the NSEC name chain. A canonical RR form and ordering + within an RRset are required to construct and verify RRSIG RRs. + +6.1 Canonical DNS Name Order + + For purposes of DNS security, owner names are ordered by treating + individual labels as unsigned left-justified octet strings. The + absence of a octet sorts before a zero value octet, and upper case + US-ASCII letters are treated as if they were lower case US-ASCII + letters. + + To compute the canonical ordering of a set of DNS names, start by + sorting the names according to their most significant (rightmost) + labels. For names in which the most significant label is identical, + continue sorting according to their next most significant label, and + so forth. + + For example, the following names are sorted in canonical DNS name + order. The most significant label is "example". At this level, + "example" sorts first, followed by names ending in "a.example", then + names ending "z.example". The names within each level are sorted in + the same way. + + example + a.example + yljkjljk.a.example + Z.a.example + zABC.a.EXAMPLE + z.example + \001.z.example + *.z.example + \200.z.example + + +6.2 Canonical RR Form + + For purposes of DNS security, the canonical form of an RR is the wire + format of the RR where: + 1. Every domain name in the RR is fully expanded (no DNS name + compression) and fully qualified; + 2. All uppercase US-ASCII letters in the owner name of the RR are + replaced by the corresponding lowercase US-ASCII letters; + + + + +Arends, et al. Expires November 15, 2004 [Page 22] + +Internet-Draft DNSSEC Resource Records May 2004 + + + 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, + HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, + SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in + the DNS names contained within the RDATA are replaced by the + corresponding lowercase US-ASCII letters; + 4. If the owner name of the RR is a wildcard name, the owner name is + in its original unexpanded form, including the "*" label (no + wildcard substitution); and + 5. The RR's TTL is set to its original value as it appears in the + originating authoritative zone or the Original TTL field of the + covering RRSIG RR. + +6.3 Canonical RR Ordering Within An RRset + + For purposes of DNS security, RRs with the same owner name, class, + and type are sorted by treating the RDATA portion of the canonical + form of each RR as a left-justified unsigned octet sequence where the + absence of an octet sorts before a zero octet. + + [RFC2181] specifies that an RRset is not allowed to contain duplicate + records (multiple RRs with the same owner name, class, type, and + RDATA). Therefore, if an implementation detects duplicate RRs when + putting the RRset in canonical form, the implementation MUST treat + this as a protocol error. If the implementation chooses to handle + this protocol error in the spirit of the robustness principle (being + liberal in what it accepts), the implementation MUST remove all but + one of the duplicate RR(s) for purposes of calculating the canonical + form of the RRset. + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 23] + +Internet-Draft DNSSEC Resource Records May 2004 + + +7. IANA Considerations + + This document introduces no new IANA considerations, because all of + the protocol parameters used in this document have already been + assigned by previous specifications. However, since the evolution of + DNSSEC has been long and somewhat convoluted, this section attempts + to describe the current state of the IANA registries and other + protocol parameters which are (or once were) related to DNSSEC. + + Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA + considerations. + + DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to + the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS + Resource Record Type 43 to DS. [RFC3755] assigned types 46, 47, + and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. [RFC3755] + also marked type 30 (NXT) as Obsolete, and restricted use of types + 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction security + protocol described in [RFC2931] and the transaction KEY Resource + Record described in [RFC2930]. + + DNS Security Algorithm Numbers: [RFC2535] created an IANA registry + for DNSSEC Resource Record Algorithm field numbers, and assigned + values 1-4 and 252-255. [RFC3110] assigned value 5. [RFC3755] + altered this registry to include flags for each entry regarding + its use with the DNS security extensions. Each algorithm entry + could refer to an algorithm that can be used for zone signing, + transaction security (see [RFC2931]) or both. Values 6-251 are + available for assignment by IETF standards action. See Appendix A + for a full listing of the DNS Security Algorithm Numbers entries + at the time of writing and their status of use in DNSSEC. + + [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and + assigned value 0 to reserved and value 1 to SHA-1. + + KEY Protocol Values: [RFC2535] created an IANA Registry for KEY + Protocol Values, but [RFC3445] re-assigned all values other than 3 + to reserved and closed this IANA registry. The registry remains + closed, and all KEY and DNSKEY records are required to have + Protocol Octet value of 3. + + Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA + registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, + this registry only contains an assignment for bit 7 (the ZONE bit) + and a reservation for bit 15 for the Secure Entry Point flag (SEP + bit) [RFC3757]. Bits 0-6 and 8-14 are available for assignment by + IETF Standards Action. + + + + +Arends, et al. Expires November 15, 2004 [Page 24] + +Internet-Draft DNSSEC Resource Records May 2004 + + +8. Security Considerations + + This document describes the format of four DNS resource records used + by the DNS security extensions, and presents an algorithm for + calculating a key tag for a public key. Other than the items + described below, the resource records themselves introduce no + security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] + and [I-D.ietf-dnsext-dnssec-protocol] for additional security + considerations related to the use of these records. + + The DS record points to a DNSKEY RR using a cryptographic digest, the + key algorithm type and a key tag. The DS record is intended to + identify an existing DNSKEY RR, but it is theoretically possible for + an attacker to generate a DNSKEY that matches all the DS fields. The + probability of constructing such a matching DNSKEY depends on the + type of digest algorithm in use. The only currently defined digest + algorithm is SHA-1, and the working group believes that constructing + a public key which would match the algorithm, key tag, and SHA-1 + digest given in a DS record would be a sufficiently difficult problem + that such an attack is not a serious threat at this time. + + The key tag is used to help select DNSKEY resource records + efficiently, but it does not uniquely identify a single DNSKEY + resource record. It is possible for two distinct DNSKEY RRs to have + the same owner name, the same algorithm type, and the same key tag. + An implementation which uses only the key tag to select a DNSKEY RR + might select the wrong public key in some circumstances. + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 25] + +Internet-Draft DNSSEC Resource Records May 2004 + + +9. Acknowledgments + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. While explicitly listing everyone who has + contributed during the decade during which DNSSEC has been under + development would be an impossible task, + [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the + participants who were kind enough to comment on these documents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 26] + +Internet-Draft DNSSEC Resource Records May 2004 + + +10. References + +10.1 Normative References + + [I-D.ietf-dnsext-dnssec-intro] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "DNS Security Introduction and Requirements", + draft-ietf-dnsext-dnssec-intro-10 (work in progress), May + 2004. + + [I-D.ietf-dnsext-dnssec-protocol] + Arends, R., Austein, R., Larson, M., Massey, D. and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in + progress), May 2004. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet + Mail Extensions) Part One: Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", RFC + 1521, September 1993. + + [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, + August 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( + SIG(0)s)", RFC 2931, September 2000. + + + +Arends, et al. Expires November 15, 2004 [Page 27] + +Internet-Draft DNSSEC Resource Records May 2004 + + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain + Name System (DNS)", RFC 3110, May 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record + (RR)", RFC 3658, December 2003. + + [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", RFC 3755, April 2004. + + [RFC3757] Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", RFC 3757, April 2004. + +10.2 Informative References + + [I-D.ietf-dnsext-nsec-rdata] + Schlyter, J., "KEY RR Secure Entry Point Flag", + draft-ietf-dnsext-nsec-rdata-05 (work in progress), March + 2004. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Drienerlolaan 5 + 7522 NB Enschede + NL + + EMail: roy.arends@telin.nl + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 28] + +Internet-Draft DNSSEC Resource Records May 2004 + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + USC Information Sciences Institute + 3811 N. Fairfax Drive + Arlington, VA 22203 + USA + + EMail: masseyd@isi.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 29] + +Internet-Draft DNSSEC Resource Records May 2004 + + +Appendix A. DNSSEC Algorithm and Digest Types + + The DNS security extensions are designed to be independent of the + underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS + resource records all use a DNSSEC Algorithm Number to identify the + cryptographic algorithm in use by the resource record. The DS + resource record also specifies a Digest Algorithm Number to identify + the digest algorithm used to construct the DS record. The currently + defined Algorithm and Digest Types are listed below. Additional + Algorithm or Digest Types could be added as advances in cryptography + warrant. + + A DNSSEC aware resolver or name server MUST implement all MANDATORY + algorithms. + +A.1 DNSSEC Algorithm Types + + The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify + the security algorithm being used. These values are stored in the + "Algorithm number" field in the resource record RDATA. + + Some algorithms are usable only for zone signing (DNSSEC), some only + for transaction security mechanisms (SIG(0) and TSIG), and some for + both. Those usable for zone signing may appear in DNSKEY, RRSIG, and + DS RRs. Those usable for transaction security would be present in + SIG(0) and KEY RRs as described in [RFC2931] + + Zone + Value Algorithm [Mnemonic] Signing References Status + ----- -------------------- --------- ---------- --------- + 0 reserved + 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED + 2 Diffie-Hellman [DH] n RFC 2539 - + 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL + 4 Elliptic Curve [ECC] TBA - + 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY + 252 Indirect [INDIRECT] n - + 253 Private [PRIVATEDNS] y see below OPTIONAL + 254 Private [PRIVATEOID] y see below OPTIONAL + 255 reserved + + 6 - 251 Available for assignment by IETF Standards Action. + +A.1.1 Private Algorithm Types + + Algorithm number 253 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with a wire encoded + + + +Arends, et al. Expires November 15, 2004 [Page 30] + +Internet-Draft DNSSEC Resource Records May 2004 + + + domain name, which MUST NOT be compressed. The domain name indicates + the private algorithm to use and the remainder of the public key area + is determined by that algorithm. Entities should only use domain + names they control to designate their private algorithms. + + Algorithm number 254 is reserved for private use and will never be + assigned to a specific algorithm. The public key area in the DNSKEY + RR and the signature area in the RRSIG RR begin with an unsigned + length byte followed by a BER encoded Object Identifier (ISO 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. + Entities should only use OIDs they control to designate their private + algorithms. + +A.2 DNSSEC Digest Types + + A "Digest Type" field in the DS resource record types identifies the + cryptographic digest algorithm used by the resource record. The + following table lists the currently defined digest algorithm types. + + VALUE Algorithm STATUS + 0 Reserved - + 1 SHA-1 MANDATORY + 2-255 Unassigned - + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 31] + +Internet-Draft DNSSEC Resource Records May 2004 + + +Appendix B. Key Tag Calculation + + The Key Tag field in the RRSIG and DS resource record types provides + a mechanism for selecting a public key efficiently. In most cases, a + combination of owner name, algorithm, and key tag can efficiently + identify a DNSKEY record. Both the RRSIG and DS resource records + have corresponding DNSKEY records. The Key Tag field in the RRSIG + and DS records can be used to help select the corresponding DNSKEY RR + efficiently when more than one candidate DNSKEY RR is available. + + However, it is essential to note that the key tag is not a unique + identifier. It is theoretically possible for two distinct DNSKEY RRs + to have the same owner name, the same algorithm, and the same key + tag. The key tag is used to limit the possible candidate keys, but it + does not uniquely identify a DNSKEY record. Implementations MUST NOT + assume that the key tag uniquely identifies a DNSKEY RR. + + The key tag is the same for all DNSKEY algorithm types except + algorithm 1 (please see Appendix B.1 for the definition of the key + tag for algorithm 1). The key tag algorithm is the sum of the wire + format of the DNSKEY RDATA broken into 2 octet groups. First the + RDATA (in wire format) is treated as a series of 2 octet groups, + these groups are then added together ignoring any carry bits. + + A reference implementation of the key tag algorithm is as an ANSI C + function is given below with the RDATA portion of the DNSKEY RR is + used as input. It is not necessary to use the following reference + code verbatim, but the numerical value of the Key Tag MUST be + identical to what the reference implementation would generate for the + same input. + + Please note that the algorithm for calculating the Key Tag is almost + but not completely identical to the familiar ones complement checksum + used in many other Internet protocols. Key Tags MUST be calculated + using the algorithm described here rather than the ones complement + checksum. + + The following ANSI C reference implementation calculates the value of + a Key Tag. This reference implementation applies to all algorithm + types except algorithm 1 (see Appendix B.1). The input is the wire + format of the RDATA portion of the DNSKEY RR. The code is written + for clarity, not efficiency. + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 32] + +Internet-Draft DNSSEC Resource Records May 2004 + + + /* + * Assumes that int is at least 16 bits. + * First octet of the key tag is the most significant 8 bits of the + * return value; + * Second octet of the key tag is the least significant 8 bits of the + * return value. + */ + + unsigned int + keytag ( + unsigned char key[], /* the RDATA part of the DNSKEY RR */ + unsigned int keysize /* the RDLENGTH */ + ) + { + unsigned long ac; /* assumed to be 32 bits or larger */ + int i; /* loop index */ + + for ( ac = 0, i = 0; i < keysize; ++i ) + ac += (i & 1) ? key[i] : key[i] << 8; + ac += (ac >> 16) & 0xFFFF; + return ac & 0xFFFF; + } + + +B.1 Key Tag for Algorithm 1 (RSA/MD5) + + The key tag for algorithm 1 (RSA/MD5) is defined differently than the + key tag for all other algorithms, for historical reasons. For a + DNSKEY RR with algorithm 1, the key tag is defined to be the most + significant 16 bits of the least significant 24 bits in the public + key modulus (in other words, the 4th to last and 3rd to last octets + of the public key modulus). + + Please note that Algorithm 1 is NOT RECOMMENDED. + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 33] + +Internet-Draft DNSSEC Resource Records May 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Arends, et al. Expires November 15, 2004 [Page 34] + +Internet-Draft DNSSEC Resource Records May 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires November 15, 2004 [Page 35] + + diff --git a/doc/draft/draft-ietf-dnsext-mdns-30.txt b/doc/draft/draft-ietf-dnsext-mdns-30.txt new file mode 100644 index 0000000000..1537573911 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-mdns-30.txt @@ -0,0 +1,1868 @@ +DNSEXT Working Group Levon Esibov +INTERNET-DRAFT Bernard Aboba +Category: Standards Track Dave Thaler + Microsoft +17 March 2004 + + + + Linklocal Multicast Name Resolution (LLMNR) + + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC 2026. + + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other groups +may also distribute working documents as Internet-Drafts. + + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference material +or to cite them other than as "work in progress." + + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + + +Copyright Notice + + +Copyright (C) The Internet Society (2004). All Rights Reserved. + + +Abstract + + +Today, with the rise of home networking, there are an increasing number +of ad-hoc networks operating without a Domain Name System (DNS) server. +In order to allow name resolution in such environments, Link-Local +Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all +current and future DNS formats, types and classes, while operating on a +separate port from DNS, and with a distinct resolver cache. + + +The goal of LLMNR is to enable name resolution in scenarios in which +conventional DNS name resolution is not possible. Since LLMNR only +operates on the local link, it cannot be considered a substitute for +DNS. + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 1] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +Table of Contents + + +1. Introduction .......................................... 3 + 1.1 Requirements .................................... 3 + 1.2 Terminology ..................................... 4 +2. Name resolution using LLMNR ........................... 4 + 2.1 LLMNR packet format ............................. 5 + 2.2 Sender behavior ................................. 8 + 2.3 Responder behavior .............................. 8 + 2.4 Unicast queries ................................. 10 + 2.5 Off-link detection .............................. 11 + 2.6 Responder responsibilities ...................... 12 + 2.7 Retransmission and jitter ....................... 12 + 2.8 DNS TTL ......................................... 13 + 2.9 Use of the authority and additional sections .... 13 +3. Usage model ........................................... 14 + 3.1 LLMNR configuration ............................. 15 +4. Conflict resolution ................................... 16 + 4.1 Considerations for multiple interfaces .......... 18 + 4.2 API issues ...................................... 19 +5. Security considerations ............................... 19 + 5.1 Scope restriction ............................... 20 + 5.2 Usage restriction ............................... 21 + 5.3 Cache and port separation ....................... 21 + 5.4 Authentication .................................. 22 +6. IANA considerations ................................... 22 +7. References ............................................ 22 + 7.1 Normative References ............................ 22 + 7.2 Informative References .......................... 23 +Acknowledgments .............................................. 24 +Authors' Addresses ........................................... 25 +Intellectual Property Statement .............................. 25 +Full Copyright Statement ..................................... 26 + + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 2] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +1. Introduction + + +This document discusses Link Local Multicast Name Resolution (LLMNR), +which utilizes the DNS packet format and supports all current and future +DNS formats, types and classes. LLMNR operates on a separate port from +the Domain Name System (DNS), with a distinct resolver cache. + + +The goal of LLMNR is to enable name resolution in scenarios in which +conventional DNS name resolution is not possible. These include +scenarios in which hosts are not configured with the address of a DNS +server, where configured DNS servers do not reply to a query, or where +they respond with errors, as described in Section 2. Since LLMNR only +operates on the local link, it cannot be considered a substitute for +DNS. + + +Link-scope multicast addresses are used to prevent propagation of LLMNR +traffic across routers, potentially flooding the network. LLMNR queries +can also be sent to a unicast address, as described in Section 2.4. + + +Propagation of LLMNR packets on the local link is considered sufficient +to enable name resolution in small networks. The assumption is that if +a network has a gateway, then the network is able to provide DNS server +configuration. Configuration issues are discussed in Section 3.1. + + +In the future, it may be desirable to consider use of multicast name +resolution with multicast scopes beyond the link-scope. This could +occur if LLMNR deployment is successful, the need for multicast name +resolution beyond the link-scope, or multicast routing becomes +ubiquitous. For example, expanded support for multicast name resolution +might be required for mobile ad-hoc networking scenarios, or where no +DNS server is available that is authoritative for the names of local +hosts, and can support dynamic DNS, such as in wireless hotspots. + + +Once we have experience in LLMNR deployment in terms of administrative +issues, usability and impact on the network, it will be possible to +reevaluate which multicast scopes are appropriate for use with multicast +name resolution. + + +Service discovery in general, as well as discovery of DNS servers using +LLMNR in particular, is outside of the scope of this document, as is +name resolution over non-multicast capable media. + + +1.1. Requirements + + +In this document, several words are used to signify the requirements of +the specification. These words are often capitalized. The key words +"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD +NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be + + + + +Esibov, Aboba & Thaler Standards Track [Page 3] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +interpreted as described in [RFC2119]. + + +1.2. Terminology + + +This document assumes familiarity with DNS terminology defined in +[RFC1035]. Other terminology used in this document includes: + + +Positively Resolved + Responses with RCODE set to zero are referred to in this document + as "positively resolved". + + +Routable Address + An address other than a Link-Local address. This includes globally + routable addresses, as well as private addresses. + + +Reachable + An address is considered reachable over a link if either an ARP or + neighbor discovery cache entry exists for the address on the link. + + +Responder + A host that listens to LLMNR queries, and responds to those for + which it is authoritative. + + +Sender + A host that sends an LLMNR query. + + +2. Name resolution using LLMNR + + +LLMNR is a peer-to-peer name resolution protocol that is not intended as +a replacement for DNS. LLMNR queries are sent to and received on port +TBD. IPv4 administratively scoped multicast usage is specified in +"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope +multicast address a given responder listens to, and to which a sender +sends queries, is TBD. The IPv6 link-scope multicast address a given +responder listens to, and to which a sender sends all queries, is TBD. + + +Typically a host is configured as both an LLMNR sender and a responder. +A host MAY be configured as a sender, but not a responder. However, a +host configured as a responder MUST act as a sender to verify the +uniqueness of names as described in Section 4. This document does not +specify how names are chosen or configured. This may occur via any +mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315]. + + +LLMNR usage MAY be configured manually or automatically on a per +interface basis. By default, LLMNR responders SHOULD be enabled on all +interfaces, at all times. Enabling LLMNR for use in situations where a +DNS server has been configured will result in a change in default +behavior without a simultaneous update to configuration information. + + + + +Esibov, Aboba & Thaler Standards Track [Page 4] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +Where this is considered undesirable, LLMNR SHOULD NOT be enabled by +default, so that hosts will neither listen on the link-scope multicast +address, nor will they send queries to that address. + + +An LLMNR sender may send a request for any name. However, by default, +LLMNR requests SHOULD be sent only when one of the following conditions +are met: + + +[1] No manual or automatic DNS configuration has been performed. If an + interface has been configured with DNS server address(es), then + LLMNR SHOULD NOT be used as the primary name resolution mechanism + on that interface, although it MAY be used as a name resolution + mechanism of last resort. + + +[2] DNS servers do not respond. + + +[3] DNS servers respond to a DNS query with RCODE=3 (Authoritative Name + Error) or RCODE=0, and an empty answer section. + + +A typical sequence of events for LLMNR usage is as follows: + + +[a] DNS servers are not configured or do not respond to a DNS query, or + respond with RCODE=3, or RCODE=0 and an empty answer section. + + +[b] An LLMNR sender sends an LLMNR query to the link-scope multicast + address(es) defined in Section 2, unless a unicast query is + indicated. A sender SHOULD send LLMNR queries for PTR RRs via + unicast, as specified in Section 2.4. + + +[c] A responder responds to this query only if it is authoritative for + the domain name in the query. A responder responds to a multicast + query by sending a unicast UDP response to the sender. Unicast + queries are responded to as indicated in Section 2.4. + + +[d] Upon reception of the response, the sender processes it. + + +Further details of sender and responder behavior are provided in the +sections that follow. + + +2.1. LLMNR packet format + + +LLMNR utilizes the DNS packet format defined in [RFC1035] Section 4 for +both queries and responses. LLMNR implementations SHOULD send UDP +queries and responses only as large as are known to be permissible +without causing fragmentation. When in doubt a maximum packet size of +512 octets SHOULD be used. LLMNR implementations MUST accept UDP +queries and responses as large as permitted by the link MTU. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 5] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +2.1.1. LLMNR header format + + +LLMNR queries and responses utilize the DNS header format defined in +[RFC1035] with exceptions noted below: + + + 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 | Z|TC| Z| Z| Z| Z| Z| RCODE | ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| QDCOUNT | ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| ANCOUNT | ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| NSCOUNT | ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +| ARCOUNT | ++--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + +where: + + +ID A 16 bit identifier assigned by the program that generates any kind + of query. This identifier is copied from the query to the response + and can be used by the sender to match responses to outstanding + queries. The ID field in a query SHOULD be set to a pseudo-random + value. + + +QR A one bit field that specifies whether this message is an LLMNR + query (0), or an LLMNR response (1). + + +OPCODE + A four bit field that specifies the kind of query in this message. + This value is set by the originator of a query and copied into the + response. This specification defines the behavior of standard + queries and responses (opcode value of zero). Future + specifications may define the use of other opcodes with LLMNR. + LLMNR senders and responders MUST support standard queries (opcode + value of zero). LLMNR queries with unsupported OPCODE values MUST + be silently discarded by responders. + + +TC TrunCation - specifies that this message was truncated due to + length greater than that permitted on the transmission channel. + The TC bit MUST NOT be set in an LLMNR query and if set is ignored + by an LLMNR responder. If the TC bit is set an LLMNR response, + then the sender MAY use the response if it contains all necessary + information, or the sender MAY discard the response and resend the + + + + +Esibov, Aboba & Thaler Standards Track [Page 6] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + + LLMNR query over TCP using the unicast address of the responder as + the destination address. See [RFC2181] and Section 2.4 of this + specification for further discussion of the TC bit. + + +Z Reserved for future use. Implementations of this specification + MUST set these bits to zero in both queries and responses. If + these bits are set in a LLMNR query or response, implementations of + this specification MUST ignore them. Since reserved bits could + conceivably be used for different purposes than in DNS, + implementors are advised not to enable processing of these bits in + an LLMNR implementation starting from a DNS code base. + + +RCODE + Response code -- this 4 bit field is set as part of LLMNR + responses. In an LLMNR query, the RCODE MUST be zero, and is + ignored by the responder. The response to a multicast LLMNR query + MUST have RCODE set to zero. A sender MUST silently discard an + LLMNR response with a non-zero RCODE sent in response to a + multicast query. + + + If an LLMNR responder is authoritative for the name in a multicast + query, but an error is encountered, the responder SHOULD send an + LLMNR response with an RCODE of zero, no RRs in the answer section, + and the TC bit set. This will cause the query to be resent using + TCP, and allow the inclusion of a non-zero RCODE in the response to + the TCP query. Responding with the TC bit set is preferrable to + not sending a response, since it enables errors to be diagnosed. + + + Since LLMNR responders only respond to LLMNR queries for names for + which they are authoritative, LLMNR responders MUST NOT respond + with an RCODE of 3; instead, they should not respond at all. + + + LLMNR implementations MUST support EDNS0 [RFC2671] and extended + RCODE values. + + +QDCOUNT + An unsigned 16 bit integer specifying the number of entries in the + question section. A sender MUST place only one question into the + question section of an LLMNR query. LLMNR responders MUST silently + discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders + MUST silently discard LLMNR responses with QDCOUNT not equal to + one. + + +ANCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the answer section. LLMNR responders MUST silently + discard LLMNR queries with ANCOUNT not equal to zero. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 7] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +NSCOUNT + An unsigned 16 bit integer specifying the number of name server + resource records in the authority records section. Authority + record section processing is described in Section 2.9. + + +ARCOUNT + An unsigned 16 bit integer specifying the number of resource + records in the additional records section. Additional record + section processing is described in Section 2.9. + + +2.2. Sender behavior + + +A sender may send an LLMNR query for any legal resource record type +(e.g. A, AAAA, SRV, etc.) to the link-scope multicast address. + + +As described in Section 2.4, a sender may also send a unicast query. +Sections 2 and 3 describe the circumstances in which LLMNR queries may +be sent. + + +The sender MUST anticipate receiving no replies to some LLMNR queries, +in the event that no responders are available within the link-scope or +in the event no positive non-null responses exist for the transmitted +query. If no positive response is received, a resolver treats it as a +response that no records of the specified type and class exist for the +specified name (it is treated the same as a response with RCODE=0 and an +empty answer section). + + +Since the responder may order the RRs in the response so as to indicate +preference, the sender SHOULD preserve ordering in the response to the +querying application. + + +2.3. Responder behavior + + +An LLMNR response MUST be sent to the sender via unicast. + + +Upon configuring an IP address responders typically will synthesize +corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR +queries for these RRs. An SOA RR is synthesized only when a responder +has another RR as well; the SOA RR MUST NOT be the only RR that a +responder has. However, in general whether RRs are manually or +automatically created is an implementation decision. + + +For example, a host configured to have computer name "host1" and to be a +member of the "example.com" domain, and with IPv4 address 10.1.1.1 and +IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be authoritative for the +following records: + + +host1. IN A 10.1.1.1 + + + + +Esibov, Aboba & Thaler Standards Track [Page 8] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + +host1.example.com. IN A 10.1.1.1 +IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6 + + +1.1.1.10.in-addr.arpa. IN PTR host1. +IN PTR host1.example.com. + + +6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa +IN PTR host1. +IN PTR host1.example.com + + +An LLMNR responder might be further manually configured with the name of +a local mail server with an MX RR included in the "host1." and +"host1.example.com." records. + + +In responding to queries: + + +[a] Responders MUST listen on UDP port TBD on the link-scope multicast + address(es) defined in Section 2, and on UDP and TCP port TBD on + the unicast address(es) that could be set as the source address(es) + when the responder responds to the LLMNR query. + + +[b] Responders MUST direct responses to the port from which the query + was sent. When queries are received via TCP this is an inherent + part of the transport protocol. For queries received by UDP the + responder MUST take note of the source port and use that as the + destination port in the response. Responses SHOULD always be sent + from the port to which they were directed. + + +[c] Responders MUST respond to LLMNR queries for names and addresses + they are authoritative for. This applies to both forward and + reverse lookups. + + +[d] Responders MUST NOT respond to LLMNR queries for names they are not + authoritative for. + + +[e] Responders MUST NOT respond using cached data. + + +[f] If a DNS server is running on a host that supports LLMNR, the DNS + server MUST respond to LLMNR queries only for the RRSets relating + to the host on which the server is running, but MUST NOT respond + for other records for which the server is authoritative. DNS + servers also MUST NOT send LLMNR queries in order to resolve DNS + queries. + + +[g] If a responder is authoritative for a name, it MAY respond with + RCODE=0 and an empty answer section, if the type of query does not + + + + +Esibov, Aboba & Thaler Standards Track [Page 9] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + + match a RR that the responder has. + + +As an example, a host configured to respond to LLMNR queries for the +name "foo.example.com." is authoritative for the name +"foo.example.com.". On receiving an LLMNR query for an A RR with the +name "foo.example.com." the host authoritatively responds with A RR(s) +that contain IP address(es) in the RDATA of the resource record. If the +responder has a AAAA RR, but no A RR, and an A RR query is received, the +responder would respond with RCODE=0 and an empty answer section. + + +In conventional DNS terminology a DNS server authoritative for a zone is +authoritative for all the domain names under the zone apex except for +the branches delegated into separate zones. Contrary to conventional +DNS terminology, an LLMNR responder is authoritative only for the zone +apex. + + +For example the host "foo.example.com." is not authoritative for the +name "child.foo.example.com." unless the host is configured with +multiple names, including "foo.example.com." and +"child.foo.example.com.". As a result, "foo.example.com." cannot reply +to an LLMNR query for "child.foo.example.com." with RCODE=3 +(authoritative name error). The purpose of limiting the name authority +scope of a responder is to prevent complications that could be caused by +coexistence of two or more hosts with the names representing child and +parent (or grandparent) nodes in the DNS tree, for example, +"foo.example.com." and "child.foo.example.com.". + + +In this example (unless this limitation is introduced) an LLMNR query +for an A resource record for the name "child.foo.example.com." would +result in two authoritative responses: RCODE=3 (authoritative name +error) received from "foo.example.com.", and a requested A record - from +"child.foo.example.com.". To prevent this ambiguity, LLMNR enabled +hosts could perform a dynamic update of the parent (or grandparent) zone +with a delegation to a child zone. In this example a host +"child.foo.example.com." would send a dynamic update for the NS and glue +A record to "foo.example.com.", but this approach significantly +complicates implementation of LLMNR and would not be acceptable for +lightweight hosts. + + +2.4. Unicast queries and responses + + +Unicast queries SHOULD be sent when: + + +[a] A sender repeats a query after it received a response with the TC + bit set to the previous LLMNR multicast query, or + + +[b] The sender queries for a PTR RR of a fully formed IP address within + the "in-addr.arpa" or "ip6.arpa" zones. + + + + +Esibov, Aboba & Thaler Standards Track [Page 10] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +A responder receiving a unicast query MUST send the response with a +source address set to the destination address field of the IP header of +the query causing the response. + + +Unicast LLMNR queries MUST be sent using TCP. Senders MUST support +sending TCP queries, and responders MUST support listening for TCP +queries. + + +Responses to TCP unicast LLMNR queries MUST be sent using TCP, using +the same connection as the query. If the sender of a TCP query receives +a response to that query not using TCP, the response MUST be silently +discarded. + + +Unicast UDP queries MUST be silently discarded. + + +If TCP connection setup cannot be completed in order to send a unicast +TCP query, this is treated as a response that no records of the +specified type and class exist for the specified name (it is treated the +same as a response with RCODE=0 and an empty answer section). + + +2.5. "Off link" detection + + +For IPv4, an "on link" address is defined as a link-local address +[IPv4Link] or an address whose prefix belongs to a subnet on the local +link. For IPv6 [RFC2460] an "on link" address is either a link-local +address, defined in [RFC2373], or an address whose prefix belongs to a +subnet on the local link. + + +A sender MUST select a source address for LLMNR queries that is "on +link". The destination address of an LLMNR query MUST be a link-scope +multicast address or an "on link" unicast address. + + +A responder MUST select a source address for responses that is "on +link". The destination address of an LLMNR response MUST be an "on link" +unicast address. + + +On receiving an LLMNR query, the responder MUST check whether it was +sent to a LLMNR multicast addresses defined in Section 2. If it was +sent to another multicast address, then the query MUST be silently +discarded. + + +Section 2.4 discusses use of TCP for LLMNR queries and responses. In +composing an LLMNR query using TCP, the sender MUST set the Hop Limit +field in the IPv6 header and the TTL field in the IPv4 header of the +response to one (1). The responder SHOULD set the TTL or Hop Limit +settings on the TCP listen socket to one (1) so that SYN-ACK packets +will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents +an incoming connection from off-link since the sender will not receive a + + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +SYN-ACK from the responder. + + +For UDP queries and responses the Hop Limit field in the IPv6 header, +and the TTL field in the IPV4 header MAY be set to any value. However, +it is RECOMMENDED that the value 255 be used for compatibility with +Apple Rendezvous. + + +Implementation note: + + + In the sockets API for IPv4 [POSIX], the IP_TTL and IP_MULTICAST_TTL + socket options are used to set the TTL of outgoing unicast and + multicast packets. The IP_RECVTTL socket option is available on some + platforms to retrieve the IPv4 TTL of received packets with + recvmsg(). [RFC2292] specifies similar options for setting and + retrieving the IPv6 Hop Limit. + + +2.6. Responder responsibilities + + +It is the responsibility of the responder to ensure that RRs returned in +LLMNR responses MUST only include values that are valid on the local +interface, such as IPv4 or IPv6 addresses valid on the local link or +names defended using the mechanism described in Section 4. In +particular: + + +[a] If a link-scope IPv6 address is returned in a AAAA RR, that address + MUST be valid on the local link over which LLMNR is used. + + +[b] If an IPv4 address is returned, it MUST be reachable through the + link over which LLMNR is used. + + +[c] If a name is returned (for example in a CNAME, MX or SRV RR), the + name MUST be resolvable on the local link over which LLMNR is used. + + +Routable addresses MUST be included first in the response, if available. +This encourages use of routable address(es) for establishment of new +connections. + + +2.7. Retransmission and jitter + + +An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine +when to retransmit an LLMNR query and how long to collect responses to +an LLMNR query. + + +If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, +then a sender MAY repeat the transmission of the query in order to +assure that it was received by a host capable of responding to it. +Retransmission of UDP queries SHOULD NOT be attempted more than 3 times. +Where LLMNR queries are sent using TCP, retransmission is handled by the + + + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +transport layer. + + +Because an LLMNR sender cannot know in advance if a query sent using +multicast will receive no response, one response, or more than one +response, the sender SHOULD wait for LLMNR_TIMEOUT in order to collect +all possible responses, rather than considering the multicast query +answered after the first response is received. A unicast query sender +considers the query answered after the first response is received, so +that it only waits for LLMNR_TIMEOUT if no response has been received. + + +An LLMNR sender SHOULD dynamically compute the value of LLMNR_TIMEOUT +for each transmission. It is suggested that the computation of +LLMNR_TIMEOUT be based on the response times for earlier LLMNR queries +sent on the same interface. + + +For example, the algorithms described in RFC 2988 [RFC2988] (including +exponential backoff) compute an RTO, which is used as the value of +LLMNR_TIMEOUT. Smaller values MAY be used for the initial RTO +(discussed in Section 2 of [RFC2988], paragraph 2.1), the minimum RTO +(discussed in Section 2 of [RFC2988], paragraph 2.4), and the maximum +RTO (discussed in Section 2 of [RFC2988], paragraph 2.5). + + +Recommended values are an initial RTO of 1 second, a minimum RTO of +200ms, and a maximum RTO of 5 seconds. In order to avoid +synchronization, the transmission of each LLMNR query and response +SHOULD delayed by a time randomly selected from the interval 0 to 100 +ms. This delay MAY be avoided by responders responding with RRs which +they have previously determined to be UNIQUE (see Section 4 for +details). + + +2.8. DNS TTL + + +The responder should use a pre-configured TTL value in the records +returned an LLMNR response. A default value of 30 seconds is +RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc +networks), the TTL value may need to be reduced. + + +Due to the TTL minimalization necessary when caching an RRset, all TTLs +in an RRset MUST be set to the same value. + + +2.9. Use of the authority and additional sections + + +Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a +concept of delegation. In LLMNR, the NS resource record type may be +stored and queried for like any other type, but it has no special +delegation semantics as it does in the DNS. Responders MAY have NS +records associated with the names for which they are authoritative, but +they SHOULD NOT include these NS records in the authority sections of + + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +responses. + + +Responders SHOULD insert an SOA record into the authority section of a +negative response, to facilitate negative caching as specified in +[RFC2308]. The owner name of this SOA record MUST be equal to the query +name. + + +Responders SHOULD NOT perform DNS additional section processing, except +as required for EDNS0 and DNSSEC. + + +Senders MUST NOT cache RRs from the authority or additional section of a +response as answers, though they may be used for other purposes such as +negative caching. + + +3. Usage model + + +Since LLMNR is a secondary name resolution mechanism, its usage is in +part determined by the behavior of DNS implementations. This document +does not specify any changes to DNS resolver behavior, such as +searchlist processing or retransmission/failover policy. However, +robust DNS resolver implementations are more likely to avoid unnecessary +LLMNR queries. + + +As noted in [DNSPerf], even when DNS servers are configured, a +significant fraction of DNS queries do not receive a response, or result +in negative responses due to missing inverse mappings or NS records that +point to nonexistent or inappropriate hosts. This has the potential to +result in a large number of unnecessary LLMNR queries. + + +[RFC1536] describes common DNS implementation errors and fixes. If the +proposed fixes are implemented, unnecessary LLMNR queries will be +reduced substantially, and so implementation of [RFC1536] is +recommended. + + +For example, [RFC1536] Section 1 describes issues with retransmission +and recommends implementation of a retransmission policy based on round +trip estimates, with exponential backoff. [RFC1536] Section 4 describes +issues with failover, and recommends that resolvers try another server +when they don't receive a response to a query. These policies are +likely to avoid unnecessary LLMNR queries. + + +[RFC1536] Section 3 describes zero answer bugs, which if addressed will +also reduce unnecessary LLMNR queries. + + +[RFC1536] Section 6 describes name error bugs and recommended searchlist +processing that will reduce unnecessary RCODE=3 (authoritative name) +errors, thereby also reducing unnecessary LLMNR queries. + + + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +3.1. LLMNR configuration + + +Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is +possible for a dual stack host to be configured with the address of a +DNS server over IPv4, while remaining unconfigured with a DNS server +suitable for use over IPv6. + + +In these situations, a dual stack host will send AAAA queries to the +configured DNS server over IPv4. However, an IPv6-only host +unconfigured with a DNS server suitable for use over IPv6 will be unable +to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms +(such as [RFC3315] and [DNSDisc]) are not yet widely deployed, and not +all DNS servers support IPv6. Therefore lack of IPv6 DNS configuration +may be a common problem in the short term, and LLMNR may prove useful in +enabling linklocal name resolution over IPv6. + + +Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], +IPv6-only hosts may not be configured with a DNS server. Where there is +no DNS server authoritative for the name of a host or the authoritative +DNS server does not support dynamic client update over IPv6 or +DHCPv6-based dynamic update, then an IPv6-only host will not be able to +do DNS dynamic update, and other hosts will not be able to resolve its +name. + + +For example, if the configured DNS server responds to AAAA RR queries +sent over IPv4 or IPv6 with an authoritative name error (RCODE=3), then +it will not be possible to resolve the names of IPv6-only hosts. In +this situation, LLMNR over IPv6 can be used for local name resolution. + + +Similarly, if a DHCPv4 server is available providing DNS server +configuration, and DNS server(s) exist which are authoritative for the A +RRs of local hosts and support either dynamic client update over IPv4 or +DHCPv4-based dynamic update, then the names of local IPv4 hosts can be +resolved over IPv4 without LLMNR. However, if no DNS server is +authoritative for the names of local hosts, or the authoritative DNS +server(s) do not support dynamic update, then LLMNR enables linklocal +name resolution over IPv4. + + +Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to +configure LLMNR on an interface. The LLMNR Enable Option, described in +[LLMNREnable], can be used to explicitly enable or disable use of LLMNR +on an interface. The LLMNR Enable Option does not determine whether or +in which order DNS itself is used for name resolution. The order in +which various name resolution mechanisms should be used can be specified +using the Name Service Search Option (NSSO) for DHCP [RFC2937], using +the LLMNR Enable Option code carried in the NSSO data. + + +It is possible that DNS configuration mechanisms will go in and out of + + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +service. In these circumstances, it is possible for hosts within an +administrative domain to be inconsistent in their DNS configuration. + + +For example, where DHCP is used for configuring DNS servers, one or more +DHCP servers can fail. As a result, hosts configured prior to the +outage will be configured with a DNS server, while hosts configured +after the outage will not. Alternatively, it is possible for the DNS +configuration mechanism to continue functioning while configured DNS +servers fail. + + +Unless unconfigured hosts periodically retry configuration, an outage in +the DNS configuration mechanism will result in hosts continuing to use +LLMNR even once the outage is repaired. Since LLMNR only enables +linklocal name resolution, this represents an unnecessary degradation in +capabilities. As a result, it is recommended that hosts without a +configured DNS server periodically attempt to obtain DNS configuration. +For example, where DHCP is used for DNS configuration, [RFC2131] +recommends a maximum retry interval of 64 seconds. In the absence of +other guidance, a default retry interval of one (1) minute is +RECOMMENDED. + + +4. Conflict resolution + + +The sender MUST anticipate receiving multiple replies to the same LLMNR +query, in the event that several LLMNR enabled computers receive the +query and respond with valid answers. When this occurs, the responses +may first be concatenated, and then treated in the same manner that +multiple RRs received from the same DNS server would; the sender +perceives no inherent conflict in the receipt of multiple responses. + + +There are some scenarios when multiple responders MAY respond to the +same query. There are other scenarios when only one responder MAY +respond to a query. Resource records for which the latter queries are +submitted are referred as UNIQUE throughout this document. The +uniqueness of a resource record depends on a nature of the name in the +query and type of the query. For example it is expected that: + + + - multiple hosts may respond to a query for an SRV type record + - multiple hosts may respond to a query for an A or AAAA type + record for a cluster name (assigned to multiple hosts in + the cluster) + - only a single host may respond to a query for an A or AAAA + type record for a name. + + +Every responder that responds to an LLMNR query AND includes a UNIQUE +record in the response: + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +[1] MUST verify that there is no other host within the scope of the + LLMNR query propagation that can return a resource record for the + same name, type and class. + + +[2] MUST NOT include a UNIQUE resource record in the response without + having verified its uniqueness. + + +Where a host is configured to issue LLMNR queries on more than one +interface, each interface should have its own independent LLMNR cache. +For each UNIQUE resource record in a given interface's configuration, +the host MUST verify resource record uniqueness on that interface. To +accomplish this, the host MUST send an LLMNR query for each UNIQUE +resource record. + + +By default, a host SHOULD be configured to behave as though all RRs are +UNIQUE. Uniqueness verification is carried out when the host: + + + - starts up or is rebooted + - wakes from sleep (if the network interface was inactive during sleep) + - is configured to respond to the LLMNR queries on an interface + enabled for transmission and reception of IP traffic + - is configured to respond to the LLMNR queries using additional + UNIQUE resource records + - detects that an interface is connected and is usable + (e.g. an IEEE 802 hardware link-state change indicating + that a cable was attached or completion of authentication + (and if needed, association) with a wireless base station + or adhoc network + + +When a host that has a UNIQUE record receives an LLMNR query for that +record, the host MUST respond. After the client receives a response, it +MUST check whether the response arrived on an interface different from +the one on which the query was sent. If the response arrives on a +different interface, the client can use the UNIQUE resource record in +response to LLMNR queries. If not, then it MUST NOT use the UNIQUE +resource record in response to LLMNR queries. + + +The name conflict detection mechanism doesn't prevent name conflicts +when previously partitioned segments are connected by a bridge. In order +to minimize the chance of conflicts in such a situation, it is +recommended that steps be taken to ensure name uniqueness. For example, +the name could be chosen randomly from a large pool of potential names, +or the name could be assigned via a process designed to guarantee +uniqueness. + + +When name conflicts are detected, they SHOULD be logged. To detect +duplicate use of a name, an administrator can use a name resolution +utility which employs LLMNR and lists both responses and responders. + + + + +Esibov, Aboba & Thaler Standards Track [Page 17] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +This would allow an administrator to diagnose behavior and potentially +to intervene and reconfigure LLMNR responders who should not be +configured to respond to the same name. + + +4.1. Considerations for Multiple Interfaces + + +A multi-homed host may elect to configure LLMNR on only one of its +active interfaces. In many situations this will be adequate. However, +should a host need to configure LLMNR on more than one of its active +interfaces, there are some additional precautions it MUST take. +Implementers who are not planning to support LLMNR on multiple +interfaces simultaneously may skip this section. + + +A multi-homed host checks the uniqueness of UNIQUE records as described +in Section 4. The situation is illustrated in figure 1. + + + ---------- ---------- + | | | | + [A] [myhost] [myhost] + + + Figure 1. Link-scope name conflict + + +In this situation, the multi-homed myhost will probe for, and defend, +its host name on both interfaces. A conflict will be detected on one +interface, but not the other. The multi-homed myhost will not be able +to respond with a host RR for "myhost" on the interface on the right +(see Figure 1). The multi-homed host may, however, be configured to use +the "myhost" name on the interface on the left. + + +Since names are only unique per-link, hosts on different links could be +using the same name. If an LLMNR client sends requests over multiple +interfaces, and receives replies from more than one, the result returned +to the client is defined by the implementation. The situation is +illustrated in figure 2. + + + ---------- ---------- + | | | | + [A] [myhost] [A] + + + + Figure 2. Off-segment name conflict + + +If host myhost is configured to use LLMNR on both interfaces, it will +send LLMNR queries on both interfaces. When host myhost sends a query +for the host RR for name "A" it will receive a response from hosts on +both interfaces. + + +Host myhost cannot distinguish between the situation shown in Figure 2, + + + + +Esibov, Aboba & Thaler Standards Track [Page 18] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +and that shown in Figure 3 where no conflict exists. + + + [A] + | | + ----- ----- + | | + [myhost] + + + Figure 3. Multiple paths to same host + + +This illustrates that the proposed name conflict resolution mechanism +does not support detection or resolution of conflicts between hosts on +different links. This problem can also occur with unicast DNS when a +multi-homed host is connected to two different networks with separated +name spaces. It is not the intent of this document to address the issue +of uniqueness of names within DNS. + + +4.2. API issues + + +[RFC2553] provides an API which can partially solve the name ambiguity +problem for applications written to use this API, since the sockaddr_in6 +structure exposes the scope within which each scoped address exists, and +this structure can be used for both IPv4 (using v4-mapped IPv6 +addresses) and IPv6 addresses. + + +Following the example in Figure 2, an application on 'myhost' issues the +request getaddrinfo("A", ...) with ai_family=AF_INET6 and +ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both +interfaces and the resolver library will return a list containing +multiple addrinfo structures, each with an associated sockaddr_in6 +structure. This list will thus contain the IPv4 and IPv6 addresses of +both hosts responding to the name 'A'. Link-local addresses will have a +sin6_scope_id value that disambiguates which interface is used to reach +the address. Of course, to the application, Figures 2 and 3 are still +indistinguishable, but this API allows the application to communicate +successfully with any address in the list. + + +5. Security Considerations + + +LLMNR is by nature a peer-to-peer name resolution protocol. It is +therefore inherently more vulnerable than DNS, since existing DNS +security mechanisms are difficult to apply to LLMNR. While tools exist +to alllow an attacker to spoof a response to a DNS query, spoofing a +response to an LLMNR query is easier since the query is sent to a link- +scope multicast address, where every host on the logical link will be +made aware of it. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 19] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +In order to address the security vulnerabilities, the following +mechanisms are contemplated: + + +[1] Scope restrictions. + + +[2] Usage restrictions. + + +[3] Cache and port separation. + + +[4] Authentication. + + +These techniques are described in the following sections. + + +5.1. Scope restriction + + +With LLMNR it is possible that hosts will allocate conflicting names for +a period of time, or that attackers will attempt to deny service to +other hosts by allocating the same name. Such attacks also allow hosts +to receive packets destined for other hosts. + + +Since LLMNR is typically deployed in situations where no trust model can +be assumed, it is likely that LLMNR queries and responses will be +unauthenticated. In the absence of authentication, LLMNR reduces the +exposure to such threats by utilizing UDP queries sent to a link-scope +multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) +fields to one (1) on TCP queries and responses. + + +Using a TTL of one (1) to set up a TCP connection in order to send a +unicast LLMNR query reduces the likelihood of both denial of service +attacks and spoofed responses. Checking that an LLMNR query is sent to +a link-scope multicast address should prevent spoofing of multicast +queries by off-link attackers. + + +While this limits the ability of off-link attackers to spoof LLMNR +queries and responses, it does not eliminate it. For example, it is +possible for an attacker to spoof a response to a frequent query (such +as an A or AAAA query for a popular Internet host), and by using a TTL +or Hop Limit field larger than one (1), for the forged response to reach +the LLMNR sender. + + +When LLMNR queries are sent to a link-scope multicast address, it is +possible that some routers may not properly implement link-scope +multicast, or that link-scope multicast addresses may leak into the +multicast routing system. + + +Setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one +in an LLMNR UDP response may enable denial of service attacks across the +Internet. However, since LLMNR responders only respond to queries for + + + + +Esibov, Aboba & Thaler Standards Track [Page 20] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +which they are authoritative, and LLMNR does not provide wildcard query +support, it is believed that this threat is minimal. + + +There also are scenarios such as public "hotspots" where attackers can +be present on the same link. These threats are most serious in wireless +networks such as 802.11, since attackers on a wired network will require +physical access to the home network, while wireless attackers may reside +outside the home. Link-layer security can be of assistance against +these threats if it is available. + + +5.2. Usage restriction + + +As noted in Sections 2 and 3, LLMNR is intended for usage in a limited +set of scenarios. + + +If an LLMNR query is sent whenever a DNS server does not respond in a +timely way, then an attacker can poison the LLMNR cache by responding to +the query with incorrect information. To some extent, these +vulnerabilities exist today, since DNS response spoofing tools are +available that can allow an attacker to respond to a query more quickly +than a distant DNS server. + + +Since LLMNR queries are sent and responded to on the local-link, an +attacker will need to respond more quickly to provide its own response +prior to arrival of the response from a legitimate responder. If an +LLMNR query is sent for an off-link host, spoofing a response in a +timely way is not difficult, since a legitimate response will never be +received. + + +The vulnerability is more serious if LLMNR is given higher priority than +DNS among the enabled name resolution mechanisms. In such a +configuration, a denial of service attack on the DNS server would not be +necessary in order to poison the LLMNR cache, since LLMNR queries would +be sent even when the DNS server is available. In addition, the LLMNR +cache, once poisoned, would take precedence over the DNS cache, +eliminating the benefits of cache separation. As a result, LLMNR is only +used as a name resolution mechanism of last resort. + + +5.3. Cache and port separation + + +In order to prevent responses to LLMNR queries from polluting the DNS +cache, LLMNR implementations MUST use a distinct, isolated cache for +LLMNR on each interface. The use of separate caches is most effective +when LLMNR is used as a name resolution mechanism of last resort, since +this minimizes the opportunities for poisoning the LLMNR cache, and +decreases reliance on it. + + +LLMNR operates on a separate port from DNS, reducing the likelihood that + + + + +Esibov, Aboba & Thaler Standards Track [Page 21] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +a DNS server will unintentionally respond to an LLMNR query. + + +5.4. Authentication + + +LLMNR implementations may not support DNSSEC or TSIG, and as a result, +responses to LLMNR queries may be unauthenticated. If authentication is +desired, and a pre-arranged security configuration is possible, then +IPsec ESP with a null-transform MAY be used to authenticate LLMNR +responses. In a small network without a certificate authority, this can +be most easily accomplished through configuration of a group pre-shared +key for trusted hosts. + + +6. IANA Considerations + + +This specification creates one new name space: the reserved bits in the +LLMNR header. These are allocated by IETF Consensus, in accordance with +BCP 26 [RFC2434]. + + +LLMNR requires allocation of a port TBD for both TCP and UDP. +Assignment of the same port for both transports is requested. + + +LLMNR requires allocation of a link-scope multicast IPv4 address TBD. +LLMNR also requires allocation of a link-scope multicast IPv6 address +TBD. + + +7. References + + +7.1. Normative References + + +[RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", RFC 1035, November 1987. + + +[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + +[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + +[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", + RFC 2308, March 1998. + + +[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC + 2365, July 1998. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 22] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + +[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + + +[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + +[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + +[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + + +[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. + + +7.2. Informative References + + +[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested + Fixes", RFC 1536, October 1993. + + +[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + +[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + +[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + + +[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic + Socket Interface Extensions for IPv6", RFC 2553, March 1999. + + +[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC + 2937, September 2000. + + +[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + +[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of + Caching", IEEE/ACM Transactions on Networking, Volume 10, + Number 5, pp. 589, October 2002. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 23] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local + unicast addresses to communicate with recursive DNS servers", + Internet draft (work in progress), draft-ietf-ipv6-dns- + discovery-07.txt, October 2002. + + +[IPV4Link] + Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration + of IPv4 Link-Local Addresses", Internet draft (work in + progress), draft-ietf-zeroconf-ipv4-linklocal-14.txt, April + 2004. + + +[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology -- + Portable Operating System Interface (POSIX). Open Group + Technical Standard: Base Specifications, Issue 6, December + 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin + + +[LLMNREnable] + Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work + in progress), draft-guttman-mdns-enable-02.txt, April 2002. + + +[NodeInfo] + Crawford, M., "IPv6 Node Information Queries", Internet draft + (work in progress), draft-ietf-ipn-gwg-icmp-name- + lookups-09.txt, May 2002. + + +Acknowledgments + + +This work builds upon original work done on multicast DNS by Bill +Manning and Bill Woodcock. Bill Manning's work was funded under DARPA +grant #F30602-99-1-0523. The authors gratefully acknowledge their +contribution to the current specification. Constructive input has also +been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert +Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron +Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van- +Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku +Savela. + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 24] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +Authors' Addresses + + +Levon Esibov +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + + +EMail: levone@microsoft.com + + +Bernard Aboba +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + + +Phone: +1 425 706 6605 +EMail: bernarda@microsoft.com + + +Dave Thaler +Microsoft Corporation +One Microsoft Way +Redmond, WA 98052 + + +Phone: +1 425 703 8835 +EMail: dthaler@microsoft.com + + +Intellectual Property Statement + + +The IETF takes no position regarding the validity or scope of any +intellectual property or other rights that might be claimed to pertain +to the implementation or use of the technology described in this +document or the extent to which any license under such rights might or +might not be available; neither does it represent that it has made any +effort to identify any such rights. Information on the IETF's +procedures with respect to rights in standards-track and standards- +related documentation can be found in BCP-11. Copies of claims of +rights made available for publication and any assurances of licenses to +be made available, or the result of an attempt made to obtain a general +license or permission for the use of such proprietary rights by +implementors or users of this specification can be obtained from the +IETF Secretariat. + + +The IETF invites any interested party to bring to its attention any +copyrights, patents or patent applications, or other proprietary rights +which may cover technology that may be required to practice this +standard. Please address the information to the IETF Executive +Director. + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 25] + + + + + + +INTERNET-DRAFT LLMNR 17 March 2004 + + + +Full Copyright Statement + + +Copyright (C) The Internet Society (2004). All Rights Reserved. +This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it or +assist in its implementation may be prepared, copied, published and +distributed, in whole or in part, without restriction of any kind, +provided that the above copyright notice and this paragraph are included +on all such copies and derivative works. However, this document itself +may not be modified in any way, such as by removing the copyright notice +or references to the Internet Society or other Internet organizations, +except as needed for the purpose of developing Internet standards in +which case the procedures for copyrights defined in the Internet +Standards process must be followed, or as required to translate it into +languages other than English. The limited permissions granted above are +perpetual and will not be revoked by the Internet Society or its +successors or assigns. This document and the information contained +herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE +INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE +INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED +WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Open Issues + + +Open issues with this specification are tracked on the following web +site: + + +http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html + + +Expiration Date + + +This memo is filed as , and expires +October 4, 2004. + + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 26] \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-nsec-rdata-06.txt b/doc/draft/draft-ietf-dnsext-nsec-rdata-06.txt new file mode 100644 index 0000000000..c8904456bb --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-nsec-rdata-06.txt @@ -0,0 +1,504 @@ + +DNS Extensions Working Group J. Schlyter, Ed. +Internet-Draft May 10, 2004 +Updates: RFC 2535, RFC TCR (if approved) +Expires: November 8, 2004 + + + DNSSEC NSEC RDATA Format + draft-ietf-dnsext-nsec-rdata-06.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on November 8, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document redefines the wire format of the "Type Bit Map" field + in the NSEC resource record RDATA format to cover the full RR type + space. + + + + + + + + + + + +Schlyter Expires November 8, 2004 [Page 1] + +Internet-Draft DNSSEC NSEC RDATA Format May 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3 + 2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4 + 2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4 + 2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4 + 2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5 + 2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5 + 2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 5 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . 6 + Informational References . . . . . . . . . . . . . . . . . . 7 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . 8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires November 8, 2004 [Page 2] + +Internet-Draft DNSSEC NSEC RDATA Format May 2004 + + +1. Introduction + + The NSEC [5] Resource Record (RR) is used for authenticated proof of + the non-existence of DNS owner names and types. The NSEC RR is based + on the NXT RR as described in RFC 2535 [2], and is similar except for + the name and typecode. The RDATA format for the NXT RR has the + limitation in that the RDATA could only carry information about the + existence of the first 127 types. RFC 2535 did reserve a bit to + specify an extension mechanism, but the mechanism was never actually + defined. + + In order to avoid the need to develop an extension mechanism into a + deployed base of DNSSEC aware servers and resolvers once the first + 127 type codes are allocated, this document redefines the wire format + of the "Type Bit Map" field in the NSEC RDATA to cover the full RR + type space. + + This document introduces a new format for the type bit map. The + properties of the type bit map format are that it can cover the full + possible range of typecodes, that it is relatively economical in the + amount of space it uses for the common case of a few types with an + owner name, that it can represent owner names with all possible types + present in packets of approximately 8.5 kilobytes and that the + representation is simple to implement. Efficient searching of the + type bitmap for the presence of certain types is not a requirement. + + For convenience and completeness this document presents the syntax + and semantics for the NSEC RR based on the specification in RFC 2535 + [2] and as updated by RFC TCR [5], thereby not introducing changes + except for the syntax of the type bit map. + + This document updates RFC 2535 [2] and RFC TCR [5]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +2. The NSEC Resource Record + + The NSEC resource record lists two separate things: the owner name of + the next RRset in the canonical ordering of the zone, and the set of + RR types present at the NSEC RR's owner name. The complete set of + NSEC RRs in a zone both indicate which RRsets exist in a zone and + also form a chain of owner names in the zone. This information is + used to provide authenticated denial of existence for DNS data, as + described in RFC 2535 [2]. + + The type value for the NSEC RR is 47. + + + +Schlyter Expires November 8, 2004 [Page 3] + +Internet-Draft DNSSEC NSEC RDATA Format May 2004 + + + The NSEC RR RDATA format is class independent and defined for all + classes. + + The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL + field. This is in the spirit of negative caching [8]. + +2.1 NSEC RDATA Wire Format + + The RDATA of the NSEC RR is as shown below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / Next Domain Name / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / List of Type Bit Map(s) / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +2.1.1 The Next Domain Name Field + + The Next Domain Name field contains the owner name of the next RR in + the canonical ordering of the zone. The value of the Next Domain + Name field in the last NSEC record in the zone is the name of the + zone apex (the owner name of the zone's SOA RR). + + A sender MUST NOT use DNS name compression on the Next Domain Name + field when transmitting an NSEC RR. + + Owner names of RRsets not authoritative for the given zone (such as + glue records) MUST NOT be listed in the Next Domain Name unless at + least one authoritative RRset exists at the same owner name. + +2.1.2 The List of Type Bit Map(s) Field + + The RR type space is split into 256 window blocks, each representing + the low-order 8 bits of the 16-bit RR type space. Each block that has + at least one active RR type is encoded using a single octet window + number (from 0 to 255), a single octet bitmap length (from 1 to 32) + indicating the number of octets used for the window block's bitmap, + and up to 32 octets (256 bits) of bitmap. + + Window blocks are present in the NSEC RR RDATA in increasing + numerical order. + + "|" denotes concatenation + + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + + + + +Schlyter Expires November 8, 2004 [Page 4] + +Internet-Draft DNSSEC NSEC RDATA Format May 2004 + + + Each bitmap encodes the low-order 8 bits of RR types within the + window block, in network bit order. The first bit is bit 0. For + window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds + to RR type 2 (NS), and so forth. For window block 1, bit 1 + corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to + 1, it indicates that an RRset of that type is present for the NSEC + RR's owner name. If a bit is set to 0, it indicates that no RRset of + that type is present for the NSEC RR's owner name. + + Since bit 0 in window block 0 refers to the non-existing RR type 0, + it MUST be set to 0. After verification, the validator MUST ignore + the value of bit 0 in window block 0. + + Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [3] + (section 3.1) or within the range reserved for assignment only to + QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in + zone data. If encountered, they must be ignored upon reading. + + Blocks with no types present MUST NOT be included. Trailing zero + octets in the bitmap MUST be omitted. The length of each block's + bitmap is determined by the type code with the largest numerical + value, within that block, among the set of RR types present at the + NSEC RR's owner name. Trailing zero octets not specified MUST be + interpretted as zero octets. + +2.1.3 Inclusion of Wildcard Names in NSEC RDATA + + If a wildcard owner name appears in a zone, the wildcard label ("*") + is treated as a literal symbol and is treated the same as any other + owner name for purposes of generating NSEC RRs. Wildcard owner names + appear in the Next Domain Name field without any wildcard expansion. + RFC 2535 [2] describes the impact of wildcards on authenticated + denial of existence. + +2.2 The NSEC RR Presentation Format + + The presentation format of the RDATA portion is as follows: + + The Next Domain Name field is represented as a domain name. + + The List of Type Bit Map(s) Field is represented as a sequence of RR + type mnemonics. When the mnemonic is not known, the TYPE + representation as described in RFC 3597 [4] (section 5) MUST be used. + +2.3 NSEC RR Example + + The following NSEC RR identifies the RRsets associated with + alfa.example.com. and identifies the next authoritative name after + + + +Schlyter Expires November 8, 2004 [Page 5] + +Internet-Draft DNSSEC NSEC RDATA Format May 2004 + + + alfa.example.com. + + alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234 + + The first four text fields specify the name, TTL, Class, and RR type + (NSEC). The entry host.example.com. is the next authoritative name + after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC + and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and + TYPE1234 RRsets associated with the name alfa.example.com. + + The RDATA section of the NSEC RR above would be encoded as: + + 0x04 'h' 'o' 's' 't' + 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' + 0x03 'c' 'o' 'm' 0x00 + 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 + 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 + 0x00 0x00 0x00 0x00 0x20 + + Assuming that the resolver can authenticate this NSEC record, it + could be used to prove that beta.example.com does not exist, or could + be used to prove there is no AAAA record associated with + alfa.example.com. Authenticated denial of existence is discussed in + RFC 2535 [2]. + +3. IANA Considerations + + This document introduces no new IANA considerations, because all of + the protocol parameters used in this document have already been + assigned by RFC TCR [5]. + +4. Security Considerations + + The update of the RDATA format and encoding does not affect the + security of the use of NSEC RRs. + +Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [3] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name + System (DNS) IANA Considerations", BCP 42, RFC 2929, September + + + +Schlyter Expires November 8, 2004 [Page 6] + +Internet-Draft DNSSEC NSEC RDATA Format May 2004 + + + 2000. + + [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) + Types", RFC 3597, September 2003. + + [5] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work + in progress), October 2003. + +Informational References + + [6] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [7] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + +Author's Address + + Jakob Schlyter (editor) + Karl Gustavsgatan 15 + Goteborg SE-411 25 + Sweden + + EMail: jakob@schlyter.se + +Appendix A. Acknowledgements + + The encoding described in this document was initially proposed by + Mark Andrews. Other encodings where proposed by David Blacka and + Michael Graff. + + + + + + + + + + + + + + + + +Schlyter Expires November 8, 2004 [Page 7] + +Internet-Draft DNSSEC NSEC RDATA Format May 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Schlyter Expires November 8, 2004 [Page 8] + +Internet-Draft DNSSEC NSEC RDATA Format May 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schlyter Expires November 8, 2004 [Page 9] + + + diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt new file mode 100644 index 0000000000..04815175fd --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-01.txt @@ -0,0 +1,1344 @@ + +DNSOP O. Kolkman +Internet-Draft RIPE NCC +Expires: August 30, 2004 R. Gieben + NLnet Labs + March 2004 + + + DNSSEC Operational Practices + draft-ietf-dnsop-dnssec-operational-practices-01.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 30, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes a set of practices for operating a DNSSEC + aware environment. The target audience is zone administrators + deploying DNSSEC that need a guide to help them chose appropriate + values for DNSSEC parameters. It also discusses operational matters + such as key rollovers, KSK and ZSK considerations and related + matters. + + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 1] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 The Use of the Term 'key' . . . . . . . . . . . . . . . . 3 + 1.2 Keeping the Chain of Trust Intact . . . . . . . . . . . . 3 + 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Time Definitions . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 Time Considerations . . . . . . . . . . . . . . . . . . . 5 + 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1 Motivations for the KSK and ZSK Functions . . . . . . . . 7 + 3.2 Key Security Considerations . . . . . . . . . . . . . . . 8 + 3.2.1 Key Validity Period . . . . . . . . . . . . . . . . . 8 + 3.2.2 Key Algorithm . . . . . . . . . . . . . . . . . . . . 8 + 3.2.3 Key Sizes . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3 Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 9 + 3.3.1 Zone-signing Key Rollovers . . . . . . . . . . . . . . 10 + 3.3.2 Key-signing Key Rollovers . . . . . . . . . . . . . . 13 + 4. Planning for Emergency Key Rollover . . . . . . . . . . . . . 14 + 4.1 KSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15 + 4.2 ZSK Compromise . . . . . . . . . . . . . . . . . . . . . . 15 + 4.3 Compromises of Keys Anchored in Resolvers . . . . . . . . 16 + 5. Parental Policies . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1 Initial Key Exchanges and Parental Policies + Considerations . . . . . . . . . . . . . . . . . . . . . . 16 + 5.2 Storing Keys So Hashes Can Be Regenerated . . . . . . . . 16 + 5.3 Security Lameness Checks . . . . . . . . . . . . . . . . . 17 + 5.4 DS Signature Validity Period . . . . . . . . . . . . . . . 17 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 + 8.2 Informative References . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 + A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 19 + B. Zone-signing Key Rollover Howto . . . . . . . . . . . . . . . 20 + C. Typographic Conventions . . . . . . . . . . . . . . . . . . . 20 + D. Document Details and Changes . . . . . . . . . . . . . . . . . 22 + D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 22 + D.2 draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 22 + Intellectual Property and Copyright Statements . . . . . . . . 23 + + + + + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 2] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +1. Introduction + + During workshops and early operational deployment tests, operators + and system administrators gained experience about operating DNSSEC + aware DNS services. This document translates these experiences into + a set of practices for zone administrators. At the time of writing, + there exists very little experience with DNSSEC in production + environments, this document should therefore explicitly not be seen + as represented 'Best Current Practices'. + + The procedures herein are focused on the maintenance of signed zones + (i.e. signing and publishing zones on authoritative servers). It is + intended that maintenance of zones such as resigning or key rollovers + be transparent to any verifying clients on the Internet. + + The structure of this document is as follows: It begins with + discussing some of the considerations with respect to timing + parameters of DNS in relation to DNSSEC (Section 2). Aspects of key + management such as key rollover schemes are described in Section 3. + Emergency rollover considerations are addressed in Section 4. The + typographic conventions used in this document are explained in + Appendix C. + + Since this is a document with operational suggestions and there are + no protocol specifications, the RFC2119 [5] language does not apply. + +1.1 The Use of the Term 'key' + + It is assumed that the reader is familiar with the concept of + asymmetric keys on which DNSSEC is based (Public Key Cryptography + [Ref to Schneider?]). Therefore, this document will use the term + 'key' rather loosely. Where it is written that 'a key is used to sign + data' it is assumed that the reader understands that it is the + private part of the key-pair that is used for signing. It is also + assumed that the reader understands that the public part of the + key-pair is published in the DNSKEY resource record and that it is + used in key-exchanges. + +1.2 Keeping the Chain of Trust Intact + + Maintaining a valid chain of trust is important because broken chains + of trust will result in data being marked as bogus, which may cause + entire (sub)domains to become invisible to verifying clients. The + administrators of secured zones have to realise that their zone is, + to their clients, part of a chain of trust. + + As mentioned in the introduction, the procedures herein are intended + to ensure maintenance of zones, such as resigning or key rollovers, + + + +Kolkman & Gieben Expires August 30, 2004 [Page 3] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + be transparent to the verifying clients on the Internet. + Administrators of secured zones will have to keep in mind that data + published on an authoritative primary server will not be immediately + seen by verifying clients; it may take some time for the data to be + transfered to other secondary authoritative nameservers, during which + period clients may be fetching data from caching non-authoritative + servers. For the verifying clients it is important that data from + secured zones can be used to build chains of trust regardless of + whether the data came directly from an authoritative server, a + caching nameserver or some middle box. Only by carefully using the + available timing parameters can a zone administrator assure that the + data necessary for verification can be obtained. + + The responsibility for maintaining the chain of trust is shared by + administrators of secured zones in the chain of trust. This is most + obvious in the case of a 'key compromise' when a trade off between + maintaining a valid chain of trust and the fact that the key has been + stolen, must be made. + + The zone administrator will have to make a tradeoff between keeping + the chain of trust intact -thereby allowing for attacks with the + compromised key- or to deliberately break the chain of trust thereby + making secured subdomains invisible to security aware resolvers. Also + see Section 4. + +2. Time in DNSSEC + + Without DNSSEC all times in DNS are relative. The SOA's refresh, + retry and expiration timers are counters that are used to determine + the time elapsed after a slave server syncronised (or tried to + syncronise) with a master server. The Time to Live (TTL) value and + the SOA minimum TTL parameter [6] are used to determine how long a + forwarder should cache data after it has been fetched from an + authoritative server. DNSSEC introduces the notion of an absolute + time in the DNS. Signatures in DNSSEC have an expiration date after + which the signature is marked as invalid and the signed data is to be + considered bogus. + +2.1 Time Definitions + + In this document we will be using a number of time related terms. + Within the context of this document the following definitions apply: + o "Signature validity period" + The period that a signature is valid. It starts at the time + specified in the signature inception field of the RRSIG RR and + ends at the time specified in the expiration field of the RRSIG + RR. + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 4] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + o "Signature publication period" + Time after which a signature (made with a specific key) is + replaced with a new signature (made with the same key). This + replacement takes place by publishing the relevant RRSIG in the + master zone file. If a signature is published at time T0 and a + new signature is published at time T1, the signature + publication period is T1 - T0. + If all signatures are refreshed at zone (re)signing then the + signature publication period is equal signature validity + period. + o "Maximum/Minimum Zone TTL" + The maximum or minimum value of all the TTLs in a zone. + +2.2 Time Considerations + + Because of the expiration of signatures, one should consider the + following. + o The Maximum Zone TTL of your zone data should be a fraction of + your signature validity period. + If the TTL would be of similar order as the signature validity + period, then all RRsets fetched during the validity period + would be cached until the signature expiration time. As a + result query load on authoritative servers would peak at + signature expiration time. + To avoid query load peaks we suggest the TTL on all the RRs in + your zone to be at least a few times smaller than your + signature validity period. + o The signature publication period should be at least one maximum + TTL smaller than the signature validity period. + Resigning a zone shortly before the end of the signature + validity period may cause simultaneous expiration of data from + caches. This in turn may lead to peaks in the load on + authoritative servers. + o The Minimum zone TTL should be long enough to both fetch and + verify all the RRs in the authentication chain. + 1. During validation, some data may expire before the + validation is complete. The validator should be able to keep + all data, until is completed. This applies to all RRs needed + to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and + the final answers i.e. the RR that is returned for the + initial query. + 2. Frequent verification causes load on recursive + nameservers. Data at delegation points, DSs, DNSKEYs and + RRSIGs benefit from caching. The TTL on those should be + relatively long. + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 5] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + We have seen events where data needed for verification of an + authentication chain had expired from caches. + We suggest the TTL on DNSKEY and DSs to be between ten minutes + and one hour. We recommend zone administrators to chose TTLs + longer than half a minute. + [Editor's Note: this observation could be implementation + specific. We are not sure if we should leave this item] + o Slave servers will need to be able to fetch newly signed zones + well before the data expires from your zone. + 'Better no answers than bad answers.' + If a properly implemented slave server is not able to contact a + master server for an extended period the data will at some + point expire and the slave server will not hand out any data. + If the server serves a DNSSEC zone than it may well happen that + the signatures expire well before the SOA expiration timer + counts down to zero. It is not possible to completely prevent + this from happening by tweaking the SOA parameters. However, + the effects can be minimized where the SOA expiration time is + equal or smaller than the signature validity period. + The consequence of an authoritative server not being able to + update a zone, whilst that zone includes expired signaturs, is + that non-secure resolvers will continue to be able to resolve + data served by the particular slave servers. Security aware + resolvers will experience problems. + We suggest the SOA expiration timer being approximately one + third or one fourth of the signature validity period. It will + allow problems with transfers from the master server to be + noticed before the actual signature time out. + We suggest that operators of nameservers with slave zones + develop 'watch dogs' to spot upcoming signature expirations in + slave zones, and take appropriate action. + When determining the value for the expiration parameter one has + to take the following into account: What are the chances that + all my secondary zones expire; How quickly can I reach an + administrator and load a valid zone? All these arguments are + not DNSSEC specific. + +3. Keys + + In the DNSSEC protocol there is only one type of key, the zone key. + With this key, the data in a zone is signed. + + To make zone re-signing and key rollovers procedures easier to + implement, it is possible to use one or more keys as Key Signing Keys + (KSK) these keys will only sign the apex DNSKEY RRs in a zone. Other + keys can be used to sign all the RRsets in a zone and are referred to + as Zone Signing Keys (ZSK). In this document we assume that KSKs are + the subset of keys that are used for key exchanges with the parents + + + +Kolkman & Gieben Expires August 30, 2004 [Page 6] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + and potentially for configuration as trusted anchors - the so called + Secure Entry Point keys (SEP). In this document we assume a + one-to-one mapping between KSK and SEP keys and we assume the SEP + flag [4] to be set on KSKs. + +3.1 Motivations for the KSK and ZSK Functions + + Differentiating between the KSK to ZSK functions has several + advantages: + + o Making the KSK stronger (i.e. using more bits in the key material) + has little operational impact since it is only used to sign a + small fraction of the zone data. + o As the KSK is only used to sign a keyset, which is most probably + updated less frequently than other data in the zone, it can be + stored separately from (and thus in a safer location than) the + ZSK. + o A KSK can be used for longer periods. + o No parent/child interaction is required when ZSKs are updated. + + The KSK is used less than ZSK, once a keyset is signed with the KSK + all the keys in the keyset can be used as ZSK. If a ZSK is + compromised, it can be simply dropped from the keyset. The new keyset + is then resigned with the KSK. + + Given the assumption that for KSKs the SEP flag is set, the KSK can + be distinguished from a ZSK by examining the flag field in the DNSKEY + RR. If the flag field is an odd number it is a KSK if it is an even + number it is a ZSK e.g. a value of 256 and a key signing key has 257. + + The zone-signing key can be used to sign all the data in a zone on a + regular basis. When a zone-signing key is to be rolled, no + interaction with the parent is needed. This allows for relatively + short "Signature Validity Periods". That is, Signature Validity + Periods of the order of days. + + The key-signing key is only to be used to sign the Key RR set from + the zone apex. If a key-signing key is to be rolled over, there will + be interactions with parties other than the zone administrator such + as the registry of the parent zone or administrators of verifying + resolvers that have the particular key configured as trusted entry + points. Hence, the "Key Usage Time" of these keys can and should be + made much longer. Although, given a long enough key, the "Key Usage + Time" can be on the order of years we suggest to plan for a "Key + Usage Time" of the order of a few months so that a key rollover + remains an operational routine. + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 7] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +3.2 Key Security Considerations + + Keys in DNSSEC have a number of parameters which should all be chosen + with care, the most important once are: size, algorithm and the key + validity period (its lifetime). + +3.2.1 Key Validity Period + + RFC2541 [2] describes a number of considerations with respect to the + security of keys. The document deals with the generation, lifetime, + size and storage of private keys. + + In Section 3 of RFC2541 [2] there are some suggestions for a key + validity period: 13 months for long-lived keys and 36 days for + transaction keys but suggestions for key sizes are not made. + + If we say long-lived keys are key-signing keys and transactions keys + are zone-signing keys, these recommendations will lead to rollovers + occurring frequently enough to become part of 'operational habits'; + the procedure does not have to be reinvented every time a key is + replaced. + +3.2.2 Key Algorithm + + We recommend you choose RSA/SHA-1 as the preferred algorithm for the + key. RSA has been developed in an open and transparent manner. As the + patent on RSA expired in 2001, its use is now also free. The current + known attacks on RSA can be defeated by making your key longer. As + the MD5 hashing algorithm is showing (theoretical) cracks, we + recommend the usage of SHA1. + +3.2.3 Key Sizes + + When choosing key sizes, zone administrators will need to take into + account how long a key will be used and how much data will be signed + during the key publication period. It is hard to give precise + recommendations but Lenstra and Verheul [9] supplied the following + table with lower bound estimates for cryptographic key sizes. Their + recommendations are based on a set of explicitly formulated parameter + settings, combined with existing data points about cryptosystems. For + details we refer to the original paper. + + [Editor's Note: DSA???] + + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 8] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + Year RSA Key Sizes Elliptic Curve Key Size + 2000 952 132 + 2001 990 135 + 2002 1028 139 + 2003 1068 140 + 2004 1108 143 + + 2005 1149 147 + 2006 1191 148 + 2007 1235 152 + 2008 1279 155 + 2009 1323 157 + + + 2010 1369 160 + 2011 1416 163 + 2012 1464 165 + 2013 1513 168 + 2014 1562 172 + + 2015 1613 173 + 2016 1664 177 + 2017 1717 180 + 2018 1771 181 + 2019 1825 185 + + + 2020 1881 188 + 2021 1937 190 + 2022 1995 193 + 2023 2054 197 + 2024 2113 198 + + 2025 2174 202 + 2026 2236 205 + 2027 2299 207 + 2028 2362 210 + 2029 2427 213 + + For example, should you wish your key to last three years from 2003, + check the RSA keysize values for 2006 in this table. In this case + 1191. + +3.3 Key Rollovers + + Key rollovers are a fact of life when using DNSSEC. A DNSSEC key + cannot be used forever (see RFC2541 [2] and Section 3.2 ). Zone + administrators who are in the process of rolling their keys have to + + + +Kolkman & Gieben Expires August 30, 2004 [Page 9] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + take into account that data published in previous versions of their + zone still lives in caches. When deploying DNSSEC, this becomes an + important consideration; ignoring data that may be in caches may lead + to loss of service for clients. + + The most pressing example of this is when zone material signed with + an old key is being validated by a resolver which does not have the + old zone key cached. If the old key is no longer present in the + current zone, this validation fails, marking the data bogus. + Alternatively, an attempt could be made to validate data which is + signed with a new key against an old key that lives in a local cache, + also resulting in data being marked bogus. + + To appreciate the situation one could think of a number of + authoritative servers that may not be instantaneously running the + same version of a zone and a security aware non-recursive resolver + that sits behind security aware caching forwarders. + + Note that KSK rollovers and ZSK rollovers are different. A zone-key + rollover can be handled in two different ways: pre-publish (Section + Section 3.3.1.1) and double signature (Section Section 3.3.1.2). The + pre-publish technique works because the key-signing key stays the + same during this ZSK rollover. With this KSK a cache is able to + validate the new keyset of a zone. With a KSK rollover a cache can + not validate the new keyset, because it does not trust the new KSK. + + [Editors note: This needs more verbose explanation, nobody will + appreciate the situation just yet. Help with text and examples is + appreciated] + +3.3.1 Zone-signing Key Rollovers + + For zone-signing key rollovers there are two ways to make sure that + during the rollover data still cached can be verified with the new + keysets or newly generated signatures can be verified with the keys + still in caches. One schema uses double signatures, it is described + in Section 3.3.1.2, the other uses key pre-publication (Section + 3.3.1.1). The pros, cons and recommendations are described in Section + 3.3.1.3. + +3.3.1.1 Pre-publish Keyset Rollover + + This section shows how to perform a ZSK rollover without the need to + sign all the data in a zone twice - the so called "prepublish + rollover". We recommend this method because it has advantages in the + case of key compromise. If the old key is compromised, the new key + has already been distributed in the DNS. The zone administrator is + then able to quickly switch to the new key and remove the compromised + + + +Kolkman & Gieben Expires August 30, 2004 [Page 10] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + key from the zone. Another major advantage is that the zone size does + not double, as is the case with the double signature ZSK rollover. A + small "HOWTO" for this kind of rollover can be found in Appendix B. + + normal pre-roll roll after + + SOA0 SOA1 SOA2 SOA3 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3) + + DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 DNSKEY11 + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) + + + normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. + DNSKEY 10 is used to sign all the data of the zone, the + zone-signing key. + pre-roll: DNSKEY 11 is introduced into the keyset. Note that no + signatures are generated with this key yet, but this does not + secure against brute force attacks on the public key. The minimum + duration of this pre-roll phase is the time it takes for the data + to propagate to the authoritative servers plus TTL value of the + keyset. This equates to two times the Maximum Zone TTL. + roll: At the rollover stage (SOA serial 1) DNSKEY 11 is used to sign + the data in the zone exclusively (i.e. all the signatures from + DNSKEY 10 are removed from the zone). DNSKEY 10 remains published + in the keyset. This way data that was loaded into caches from + version 1 of the zone can still be verified with key sets fetched + from version 2 of the zone. + The minimum time that the keyset including DNSKEY 10 is to be + published is the time that it takes for zone data from the + previous version of the zone to expire from old caches i.e. the + time it takes for this zone to propagate to all authoritative + servers plus the Maximum Zone TTL value of any of the data in the + previous version of the zone. + after: DNSKEY 10 is removed from the zone. The keyset, now only + containing DNSKEY 11 is resigned with the DNSKEY 1. + + The above scheme can be simplified by always publishing the "future" + key immediately after the rollover. The scheme would look as follows + (we show two rollovers); the future key is introduced in "after" as + DNSKEY 12 and again a newer one, numbered 13, in "2nd after": + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 11] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + normal roll after 2nd roll 2nd after + + SOA0 SOA2 SOA3 SOA4 SOA5 + RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5) + + DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY11 DNSKEY11 DNSKEY12 + DNSKEY11 DNSKEY11 DNSKEY12 DNSKEY12 DNSKEY13 + RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) + RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY) RRSIG12(DNSKEY) RRSIG12(DNSKEY) + + + Note that the key introduced after the rollover is not used for + production yet; the private key can thus be stored in a physically + secure manner and does not need to be 'fetched' every time a zone + needs to be signed. + + This scheme has the benefit that the key that is intended for future + use: immediately during an emergency rollover assuming that the + private key was stored in a physically secure manner. + +3.3.1.2 Double Signature Zone-signing Key Rollover + + This section shows how to perform a ZSK key rollover using the double + zone data signature scheme, aptly named "double sig rollover". + + During the rollover stage the new version of the zone file will need + to propagate to all authoritative servers and the data that exists in + (distant) caches will need to expire, this will take at least the + maximum Zone TTL . + + normal roll after + + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) + RRSIG11(SOA1) + + DNSKEY1 DNSKEY1 DNSKEY1 + DNSKEY10 DNSKEY10 DNSKEY11 + DNSKEY11 + RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) + RRSIG11(DNSKEY) + + normal: Version 0 of the zone: DNSKEY 1 is the key-signing key. + DNSKEY 10 is used to sign all the data of the zone, the + zone-signing key. + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 12] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + roll: At the rollover stage (SOA serial 1) DNSKEY 11 is introduced + into the keyset and all the data in the zone is signed with DNSKEY + 10 and DNSKEY 11. The rollover period will need to exist until all + data from version 0 of the zone has expired from remote caches. + This will take at least the maximum Zone TTL of version 0 of the + zone. + after: DNSKEY 10 is removed from the zone. All the signatures from + DNSKEY 10 are removed from the zone. The keyset, now only + containing DNSKEY 11, is resigned with DNSKEY 1. + + At every instance the data from the previous version of the zone can + be verified with the key from the current version and vice verse. The + data from the current version can be verified with the data from the + previous version of the zone. The duration of the rollover phase and + the period between rollovers should be at least the "Maximum Zone + TTL". + + Making sure that the rollover phase lasts until the signature + expiration time of the data in version 0 of the zone is recommended. + However, this date could be considerably longer than the Maximum Zone + TTL, making the rollover a lengthy procedure. + + Note that in this example we assumed that the zone was not modified + during the rollover. New data can be introduced in the zone as long + as it is signed with both keys. + +3.3.1.3 Pros and Cons of the Schemes + + Prepublish-keyset rollover: This rollover does not involve signing + the zone data twice. Instead, just before the actual rollover, the + new key is published in the keyset and thus available for + cryptanalysis attacks. A small disavantage is that this process + requires four steps. Also the prepublish scheme will not work for + KSKs as explained in Section 3.3. + Double signature rollover: The drawback of this signing scheme is + that during the rollover the number of signatures in your zone + doubles, this may be prohibitive if you have very big zones. An + advantage is that it only requires three steps. + +3.3.2 Key-signing Key Rollovers + + For the rollover of a key-signing key the same considerations as for + the rollover of a zone-signing key apply. However we can use a double + signature scheme to guarantee that old data (only the apex keyset) in + caches can be verified with a new keyset and vice versa. + + Since only the keyset is signed with a KSK, zone size considerations + do not apply. + + + +Kolkman & Gieben Expires August 30, 2004 [Page 13] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + normal roll after + + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) + + DNSKEY1 DNSKEY1 DNSKEY2 + DNSKEY2 + DNSKEY10 DNSKEY10 DNSKEY10 + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) + RRSIG2 (DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) + + normal: Version 0 of the zone. The parental DS points to DNSKEY1. + Before the rollover starts the child will have to verify what the + TTL is of the DS RR that points to DNSKEY1 - it is needed during + the rollover and we refer to the value as TTL_DS. + roll: During the rollover phase the zone administrator generates a + second KSK, DNSKEY2. The key is provided to the parent and the + child will have to wait until a new DS RR has been generated that + points to DNSKEY2. After that DS RR has been published on _all_ + servers authoritative for the parents zone, the zone administrator + has to wait at least TTL_DS to make sure that the old DS RR has + expired from distant caches. + after: DNSKEY1 has been removed. + + The scenario above puts the responsibility for maintaining a valid + chain of trust with the child. It also is based on the premises that + the parent only has one DS RR (per algorithm) per zone. St John [The + draft has expired] proposed a mechanism where using an established + trust relation, the interaction can be performed in-band. In this + mechanism there are periods where there are two DS RRs at the parent. + + [Editors note: We probably need to mention more] + +4. Planning for Emergency Key Rollover + + This section deals with preparation for a possible key compromise. + Our advice is to have a documented procedure ready for when a key + compromise is suspected or confirmed. + + [Editors note: We are much in favor of a rollover tactic that keeps + the authentication chain intact as long as possible. This means that + one has to take all the regular rollover properties into account.] + + When the private material of one of your keys is compromised it can + be used for as long as a valid authentication chain exists. An + authentication chain remains intact for: + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 14] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + o as long as a signature over the compromised key in the + authentication chain is valid, + o as long as a parental DS RR (and signature) points to the + compromised key, + o as long as the key is anchored in a resolver and is used as a + starting point for validation. (This is the hardest to update.) + While an authentication chain to your compromised key exists, your + name-space is vulnerable to abuse by the malicious key holder (i.e. + the owner of the compromised key). Zone operators have to make a + trade off if the abuse of the compromised key is worse than having + data in caches that cannot be validated. If the zone operator chooses + to break the authentication chain to the compromised key, data in + caches signed with this key cannot be validated. However, if the zone + administrator chooses to take the path of a regular roll-over, the + malicious key holder can spoof data so that it appears to be valid, + note that this kind of attack will usually be localised in the + Internet topology. + + +4.1 KSK Compromise + + When the KSK has been compromised the parent must be notified as soon + as possible using secure means. The keyset of the zone should be + resigned as soon as possible. Care must be taken to not break the + authentication chain. The local zone can only be resigned with the + new KSK after the parent's zone has been updated with the new KSK. + Before this update takes place it would be best to drop the security + status of a zone all together: the parent removes the DS of the child + at the next zone update. After that the child can be made secure + again. + + An additional danger of a key compromise is that the compromised key + can be used to facilitate a legitimate DNSKEY/DS and/or nameserver + rollover at the parent. When that happens the domain can be in + dispute. An out of band and secure notify mechanism to contact a + parent is needed in this case. + +4.2 ZSK Compromise + + Primarily because there is no parental interaction required when a + ZSK is compromised, the situation is less severe than with with a KSK + compromise. The zone must still be resigned with a new ZSK as soon + as possible. As this is a local operation and requires no + communication between the parent and child this can be achieved + fairly quickly. However, one has to take into account that just as + with a normal rollover the immediate disappearance from the old + compromised key may lead to verification problems. The + pre-publication scheme as discussed above minimises such problems. + + + +Kolkman & Gieben Expires August 30, 2004 [Page 15] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +4.3 Compromises of Keys Anchored in Resolvers + + A key can also be pre-configured in resolvers. If DNSSEC is rolled + out as planned the root key should be pre-configured in every secure + aware resolver on the planet. [Editors Note: add more about + authentication of a newly received resolver key] + + If trust-anchor keys are compromised, the resolvers using these keys + should be notified of this fact. Zone administrators may consider + setting up a mailing list to communicate the fact that a SEP key is + about to be rolled over. This communication will of course need to be + authenticated e.g. by using digital signatures. + +5. Parental Policies + +5.1 Initial Key Exchanges and Parental Policies Considerations + + The initial key exchange is always subject to the policies set by the + parent (or its registry). When designing a key exchange policy one + should take into account that the authentication and authorisation + mechanisms used during a key exchange should be as strong as the + authentication and authorisation mechanisms used for the exchange of + delegation information between parent and child. + + Using the DNS itself as the source for the actual DNSKEY material, + with an off-band check on the validity of the DNSKEY, has the benefit + that it reduces the chances of user error. A parental DNSKEY download + tool can make use of the SEP bit [4] to select the proper key from a + DNSSEC keyset; thereby reducing the chance that the wrong DNSKEY is + sent. It can validate the self-signature over a key; thereby + verifying the ownership of the private key material. Fetching the + DNSKEY from the DNS ensures that the child will not become bogus once + the parent publishes the DS RR indicating the child is secure. + + Note: the off-band verification is still needed when the key-material + is fetched by a tool. The parent can not be sure whether the DNSKEY + RRs have been spoofed. + +5.2 Storing Keys So Hashes Can Be Regenerated + + When designing a registry system one should consider if the DNSKEYs + and/or the corresponding DSs are stored. Storing DNSKEYs will help + during troubleshooting while the overhead of calculating DS records + from them is minimal. + + Having an out-of-band mechanism, such as a Whois database, to find + out which keys are used to generate DS Resource Records for specific + owners may also help with troubleshooting. + + + +Kolkman & Gieben Expires August 30, 2004 [Page 16] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +5.3 Security Lameness Checks + + Security Lameness is defined as what happens when a parent has a DS + Resource Record pointing to a non-existing DNSKEY RR. During key + exchange a parent should make sure that the child's key is actually + configured in the DNS before publishing a DS RR in its zone. Failure + to do so would render the child's zone being marked as bogus. + + Child zones should be very careful removing DNSKEY material, + specifically SEP keys, for which a DS RR exists. + + Once a zone is "security lame" a fix (e.g. by removing a DS RR) will + take time to propagate through the DNS. + +5.4 DS Signature Validity Period + + Since the DS can be replayed as long as it has a valid signature a + short signature validity period over the DS minimises the time a + child is vulnerable in the case of a compromise of the child's + KSK(s). A signature validity period that is too short introduces the + possibility that a zone is marked bogus in case of a configuration + error in the signer; there may not be enough time to fix the problems + before signatures expire. Something as mundane as operator + unavailability during weekends shows the need for DS signature + lifetimes longer than 2 days. We recommend the minimum for a DS + signature validity period to be a few days. + + The maximum signature lifetime of the DS record depends on how long + child zones are willing to be vulnerable after a key compromise. We + consider a signature validity period of around one week to be a good + compromise between the operational constraints of the parent and + minimising damage for the child. + +6. Security Considerations + + DNSSEC adds data integrity to the DNS. This document tries to assess + considerations to operate a stable and secure DNSSEC service. Not + taking into account the 'data propagation' properties in the DNS will + cause validation failures and may make secured zones unavailable to + security aware resolvers. + +7. Acknowledgments + + We, the folk mentioned as authors, only acted as editors. Most of the + ideas in this draft were the result of collective efforts during + workshops, discussions and try outs. + + At the risk of forgetting individuals who where the original + + + +Kolkman & Gieben Expires August 30, 2004 [Page 17] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + contributors of the ideas we would like to acknowledge people who + where actively involved in the compilation of this document. In + random order: Olafur Gudmundsson, Wesley Griffin, Michael Richardson, + Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette and Olivier + Courtay, Sam Weiler. + + Emma Bretherick and Adrian Bedford corrected many of the spelling and + style issues. + + Kolkman and Gieben take the blame for introducing all miscakes(SIC). + +8. References + +8.1 Normative References + + [1] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [2] Eastlake, D., "DNS Security Operational Considerations", RFC + 2541, March 1999. + + [3] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [4] Lewis, E., Kolkman, O. and J. Schlyter, "KEY RR Key-Signing Key + (KSK) Flag", draft-ietf-dnsext-keyrr-key-signing-flag-06 (work + in progress), February 2003. + +8.2 Informative References + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [7] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-13 (work in progress), March + 2003. + + [8] Arends, R., "Protocol Modifications for the DNS Security + Extensions", draft-ietf-dnsext-dnssec-protocol-01 (work in + progress), March 2003. + + [9] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", + The Journal of Cryptology 14 (255-293), 2001. + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 18] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + The Netherlands + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Miek Gieben + NLnet Labs + Kruislaan 419 + Amsterdam 1098 VA + The Netherlands + + EMail: miek@nlnetlabs.nl + URI: http://www.nlnetlabs.nl + +Appendix A. Terminology + + In this document there is some jargon used that is defined in other + documents. In most cases we have not copied the text from the + documents defining the terms but given a more elaborate explanation + of the meaning. Note that these explanations should not be seen as + authoritative. + + Private and Public Keys: DNSSEC secures the DNS through the use of + public key cryptography. Public key cryptography is based on the + existence of two keys, a public key and a private key. The public + keys are published in the DNS by use of the DNSKEY Resource Record + (DNSKEY RR). Private keys should remain private i.e. should not be + exposed to parties not-authorised to do the actual signing. + Signer: The system that has access to the private key material and + signs the Resource Record sets in a zone. A signer may be + configured to sign only parts of the zone e.g. only those RRsets + for which existing signatures are about to expire. + KSK: A Key-Signing Key (KSK) is a key that is used exclusively for + signing the apex keyset. The fact that a key is a KSK is only + relevant to the signing tool. + ZSK: A Zone Signing Key (ZSK) is a key that is used for signing all + data in a zone. The fact that a key is a ZSK is only relevant to + the signing tool. + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 19] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + SEP Key: A KSK that has a parental DS record pointing to it. Note: + this is not enforced in the protocol. A SEP Key with no parental + DS is security lame. + Anchored Key: A DNSKEY configured in resolvers around the globe. This + Key is hard to update, hence the term anchored. + Bogus: [Editors Note: a reference here] An RRset in DNSSEC is marked + "Bogus" when a signature of a RRset does not validate against the + DNSKEY. Even if the key itself was not marked Bogus. A cache may + choose to cache Bogus data for various reasons. + Singing the Zone File: The term used for the event where an + administrator joyfully signs its zone file while producing melodic + sound patterns. + Zone Administrator: The 'role' that is responsible for signing a zone + and publishing it on the primary authoritative server. + +Appendix B. Zone-signing Key Rollover Howto + + Using the pre-published signature scheme and the most conservative + method to assure oneself that data does not live in distant caches + here follows the "HOWTO". [WES: has some comments about this] + Key notation: + Step 0: The preparation: Create two keys and publish both in your + keyset. Mark one of the keys as "active" and the other as + "published". Use the "active" key for signing your zone data. + Store the private part of the "published" key, preferably + off-line. + Step 1: Determine expiration: At the beginning of the rollover make a + note of the highest expiration time of signatures in your zone + file created with the current key marked as "active". + Wait until the expiration time marked in Step 1 has passed + Step 2: Then start using the key that was marked as "published" to + sign your data i.e. mark it as "active". Stop using the key that + was marked as "active", mark it as "rolled". + Step 3: It is safe to engage in a new rollover (Step 1) after at + least one "signature validity period". + +Appendix C. Typographic Conventions + + The following typographic conventions are used in this document: + Key notation: A key is denoted by KEYx, where x is a number, x could + be thought of as the key id. + RRset notations: RRs are only denoted by the type. All other + information - owner, class, rdata and TTL - is left out. Thus: + example.com 3600 IN A 192.168.1.1 is reduced to: A. RRsets are a + list of RRs. A example of this would be: A1,A2, specifying the + RRset containing two A records. This could again be abbreviated to + just: A. + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 20] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + Signature notation: Signatures are denoted as RRSIGx(RRset), which + means that RRset is signed with DNSKEYx. + Zone representation: Using the above notation we have simplified the + representation of a signed zone by leaving out all unnecessary + details such as the names and by representing all data by "SOAx" + SOA representation: SOA's are represented as SOAx, where x is the + serial number. + Using this notation the following zone : + + + example.net. 600 IN SOA ns.example.net. ernie.example.net. ( + 10 ; serial + 450 ; refresh (7 minutes 30 seconds) + 600 ; retry (10 minutes) + 345600 ; expire (4 days) + 300 ; minimum (5 minutes) + ) + 600 RRSIG SOA 5 2 600 20130522213204 ( + 20130422213204 14 example.net. + cmL62SI6iAX46xGNQAdQ... ) + 600 NS a.iana-servers.net. + 600 NS b.iana-servers.net. + 600 RRSIG NS 5 2 600 20130507213204 ( + 20130407213204 14 example.net. + SO5epiJei19AjXoUpFnQ ... ) + 3600 DNSKEY 256 3 5 ( + EtRB9MP5/AvOuVO0I8XDxy0... + ) ; key id = 14 + 3600 DNSKEY 256 3 5 ( + gsPW/Yy19GzYIY+Gnr8HABU... + ) ; key id = 15 + 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( + 20130422213204 14 example.net. + J4zCe8QX4tXVGjV4e1r9... ) + 3600 RRSIG DNSKEY 5 2 3600 20130522213204 ( + 20130422213204 15 example.net. + keVDCOpsSeDReyV6O... ) + 600 NSEC a.example.net. NS SOA TXT RRSIG DNSKEY NSEC + 600 RRSIG NSEC 5 2 600 20130507213204 ( + 20130407213204 14 example.net. + obj3HEp1GjnmhRjX... ) + a.example.net. 600 IN TXT "A label" + 600 RRSIG TXT 5 3 600 20130507213204 ( + 20130407213204 14 example.net. + IkDMlRdYLmXH7QJnuF3v... ) + 600 NSEC b.example.com. TXT RRSIG NSEC + 600 RRSIG NSEC 5 3 600 20130507213204 ( + 20130407213204 14 example.net. + + + +Kolkman & Gieben Expires August 30, 2004 [Page 21] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + bZMjoZ3bHjnEz0nIsPMM... ) + + ... + + + is reduced to the following represenation: + + SOA10 + RRSIG14(SOA10) + + DNSKEY14 + DNSKEY15 + + RRSIG14(KEY) + RRSIG15(KEY) + + The rest of the zone data has the same signature as the SOA record, + i.e a RRSIG created with DNSKEY 14. + +Appendix D. Document Details and Changes + + This section is to be removed by the RFC editor if and when the + document is published. + + $Header: /var/cvs/dnssec-key/ + draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.22 2004/05/12 + 08:29:11 dnssec Exp $ + +D.1 draft-ietf-dnsop-dnssec-operational-practices-00 + + Submission as working group document. This document is a modified and + updated version of draft-kolkman-dnssec-operational-practices-00. + +D.2 draft-ietf-dnsop-dnssec-operational-practices-01 + + changed the definition of "Bogus" to reflect the one in the protocol + draft. + + Bad to Bogus + + Style and spelling corrections + + KSK - SEP mapping made explicit. + + Updates from Sam Weiler added + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 22] + +Internet-Draft DNSSEC Operational Practices March 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + + + +Kolkman & Gieben Expires August 30, 2004 [Page 23] + +Internet-Draft DNSSEC Operational Practices March 2004 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires August 30, 2004 [Page 24] + +