diff --git a/doc/draft/draft-ietf-dnsext-dns-threats-06.txt b/doc/draft/draft-ietf-dnsext-dns-threats-06.txt new file mode 100644 index 0000000000..6540f0def2 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dns-threats-06.txt @@ -0,0 +1,895 @@ + + +Network Working Group D. Atkins +draft-ietf-dnsext-dns-threats-06.txt IHTFP Consulting + R. Austein + ISC + February 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 21 August 2004 [Page 1] + +draft-ietf-dnsext-dns-threats-06.txt February 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 21 August 2004 [Page 2] + +draft-ietf-dnsext-dns-threats-06.txt February 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 21 August 2004 [Page 3] + +draft-ietf-dnsext-dns-threats-06.txt February 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 21 August 2004 [Page 4] + +draft-ietf-dnsext-dns-threats-06.txt February 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 Games + + Perhaps the most interesting class of DNS-specific threats are the + name-based attacks. There are several variations within this class, + sometimes called "cache poisoning" or "fake authority" attacks. What + all of these attacks have in common is that they all involve DNS RRs + whose RDATA portion (right hand side) includes 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. + + The general form of a name-based 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). + + + +Atkins & Austein Expires 21 August 2004 [Page 5] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + - 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-based attacks in the sense + discussed here. However, in the case of name-based 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-based attacks merit special + attention. + + The common thread in all of the name-based 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 + 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 + + + +Atkins & Austein Expires 21 August 2004 [Page 6] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + 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-based 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 + 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 + + + +Atkins & Austein Expires 21 August 2004 [Page 7] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + 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 + 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, + + + +Atkins & Austein Expires 21 August 2004 [Page 8] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + 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 + 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: + + + + +Atkins & Austein Expires 21 August 2004 [Page 9] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + - 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 + "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. + + + +Atkins & Austein Expires 21 August 2004 [Page 10] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + - 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. + +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. + + + + +Atkins & Austein Expires 21 August 2004 [Page 11] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + 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. + +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 + + + +Atkins & Austein Expires 21 August 2004 [Page 12] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + 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 + 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. + + + +Atkins & Austein Expires 21 August 2004 [Page 13] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + [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. + + [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. + + + + +Atkins & Austein Expires 21 August 2004 [Page 14] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + +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 + 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 + + + +Atkins & Austein Expires 21 August 2004 [Page 15] + +draft-ietf-dnsext-dns-threats-06.txt February 2004 + + + 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 21 August 2004 [Page 16] + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt new file mode 100644 index 0000000000..bcc2b4ec51 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt @@ -0,0 +1,442 @@ + + +INTERNET-DRAFT Samuel Weiler +Expires: June 2004 December 15, 2003 +Updates: RFC 2535, [DS] + + Legacy Resolver Compatibility for Delegation Signer + draft-ietf-dnsext-dnssec-2535typecode-change-06.txt + +Status of this Memo + + This document is an Internet-Draft and is subject to 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/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Comments should be sent to the author or to the DNSEXT WG mailing + list: namedroppers@ops.ietf.org + +Abstract + + As the DNS Security (DNSSEC) specifications have evolved, the + syntax and semantics of the DNSSEC resource records (RRs) have + changed. Many deployed nameservers understand variants of these + semantics. Dangerous interactions can occur when a resolver that + understands an earlier version of these semantics queries an + authoritative server that understands the new delegation signer + semantics, including at least one failure scenario that will cause + an unsecured zone to be unresolvable. This document changes the + type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to + avoid those interactions. + +Changes between 05 and 06: + + Signifigantly reworked the IANA section -- went back to one + algorithm registry. + + Removed Diffie-Hellman from the list of zone-signing algorithms + (leaving only DSA, RSA/SHA-1, and private algorithms). + + Added a DNSKEY flags field registry. + +Changes between 04 and 05: + + IESG approved publication. + + Cleaned up an internal reference in the acknowledgements section. + + Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference. + + Changed the names of both new registries. Added algorithm + mnemonics to the new zone signing algorithm registry. Minor + rewording in the IANA section for clarity. + + Cleaned up formatting of references. Replaced unknown-rr draft + references with RFC3597. Bumped DS version number. + +Changes between 03 and 04: + + Clarified that RRSIG(0) may be defined by standards action. + + Created a new algorithm registry and renamed the old algorithm + registry for SIG(0) only. Added references to the appropriate + crypto algorithm and format specifications. + + Several minor rephrasings. + +Changes between 02 and 03: + + KEY (as well as SIG) retained for SIG(0) use only. + +Changes between 01 and 02: + + SIG(0) still uses SIG, not RRSIG. Added 2931 reference. + + Domain names embedded in NSECs and RRSIGs are not compressible and + are not downcased. Added unknown-rrs reference (as informative). + + Simplified the last paragraph of section 3 (NSEC doesn't always + signal a negative answer). + + Changed the suggested type code assignments. + + Added 2119 reference. + + Added definitions of "unsecure delegation" and "unsecure referral", + since they're not clearly defined elsewhere. + + Moved 2065 to informative references, not normative. + +1. Introduction + + The DNSSEC protocol has been through many iterations whose syntax + and semantics are not completely compatible. This has occurred as + part of the ordinary process of proposing a protocol, implementing + it, testing it in the increasingly complex and diverse environment + of the Internet, and refining the definitions of the initial + Proposed Standard. In the case of DNSSEC, the process has been + complicated by DNS's criticality and wide deployment and the need + to add security while minimizing daily operational complexity. + + A weak area for previous DNS specifications has been lack of detail + in specifying resolver behavior, leaving implementors largely on + their own to determine many details of resolver function. This, + combined with the number of iterations the DNSSEC spec has been + through, has resulted in fielded code with a wide variety of + behaviors. This variety makes it difficult to predict how a + protocol change will be handled by all deployed resolvers. The + risk that a change will cause unacceptable or even catastrophic + failures makes it difficult to design and deploy a protocol change. + One strategy for managing that risk is to structure protocol + changes so that existing resolvers can completely ignore input that + might confuse them or trigger undesirable failure modes. + + This document addresses a specific problem caused by Delegation + Signer's [DS] introduction of new semantics for the NXT RR that are + incompatible with the semantics in RFC 2535 [RFC2535]. Answers + provided by DS-aware servers can trigger an unacceptable failure + mode in some resolvers that implement RFC 2535, which provides a + great disincentive to sign zones with DS. The changes defined in + this document allow for the incremental deployment of DS. + +1.1 Terminology + + In this document, the term "unsecure delegation" means any + delegation for which no DS record appears at the parent. An + "unsecure referral" is an answer from the parent containing an NS + RRset and a proof that no DS record exists for that name. + + 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 [RFC2119]. + +1.2 The Problem + + Delegation Signer introduces new semantics for the NXT RR that are + incompatible with the semantics in RFC 2535. In RFC 2535, NXT + records were only required to be returned as part of a + non-existence proof. With DS, an unsecure referral returns, in + addition to the NS, a proof of non-existence of a DS RR in the form + of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was + to interpret a response with both an NS and an NXT in the authority + section, RCODE=0, and AA=0. Some widely deployed 2535-aware + resolvers interpret any answer with an NXT as a proof of + non-existence of the requested record. This results in unsecure + delegations being invisible to 2535-aware resolvers and violates + the basic architectural principle that DNSSEC must do no harm -- + the signing of zones must not prevent the resolution of unsecured + delegations. + +2. Possible Solutions + + This section presents several solutions that were considered. + Section 3 describes the one selected. + +2.1. Change SIG, KEY, and NXT type codes + + To avoid the problem described above, legacy (RFC2535-aware) + resolvers need to be kept from seeing unsecure referrals that + include NXT records in the authority section. The simplest way to + do that is to change the type codes for SIG, KEY, and NXT. + + The obvious drawback to this is that new resolvers will not be able + to validate zones signed with the old RRs. This problem already + exists, however, because of the changes made by DS, and resolvers + that understand the old RRs (and have compatibility issues with DS) + are far more prevalent than 2535-signed zones. + +2.2. Change a subset of type codes + + The observed problem with unsecure referrals could be addressed by + changing only the NXT type code or another subset of the type codes + that includes NXT. This has the virtue of apparent simplicity, but + it risks introducing new problems or not going far enough. It's + quite possible that more incompatibilities exist between DS and + earlier semantics. Legacy resolvers may also be confused by seeing + records they recognize (SIG and KEY) while being unable to find + NXTs. Although it may seem unnecessary to fix that which is not + obviously broken, it's far cleaner to change all of the type codes + at once. This will leave legacy resolvers and tools completely + blinded to DNSSEC -- they will see only unknown RRs. + +2.3. Replace the DO bit + + Another way to keep legacy resolvers from ever seeing DNSSEC + records with DS semantics is to have authoritative servers only + send that data to DS-aware resolvers. It's been proposed that + assigning a new EDNS0 flag bit to signal DS-awareness (tentatively + called "DA"), and having authoritative servers send DNSSEC data + only in response to queries with the DA bit set, would accomplish + this. This bit would presumably supplant the DO bit described in + RFC 3225. + + This solution is sufficient only if all 2535-aware resolvers zero + out EDNS0 flags that they don't understand. If one passed through + the DA bit unchanged, it would still see the new semantics, and it + would probably fail to see unsecure delegations. Since it's + impractical to know how every DNS implementation handles unknown + EDNS0 flags, this is not a universal solution. It could, though, + be considered in addition to changing the RR type codes. + +2.4. Increment the EDNS version + + Another possible solution is to increment the EDNS version number + as defined in RFC 2671 [RFC2671], on the assumption that all + existing implementations will reject higher versions than they + support, and retain the DO bit as the signal for DNSSEC awareness. + This approach has not been tested. + +2.5. Do nothing + + There is a large deployed base of DNS resolvers that understand + DNSSEC as defined by the standards track RFC 2535 and RFC 2065 + and, due to under specification in those documents, interpret any + answer with an NXT as a non-existence proof. So long as that is + the case, zone owners will have a strong incentive to not sign any + zones that contain unsecure delegations, lest those delegations be + invisible to such a large installed base. This will dramatically + slow DNSSEC adoption. + + Unfortunately, without signed zones there's no clear incentive for + operators of resolvers to upgrade their software to support the new + version of DNSSEC, as defined in [DS]. Historical data suggests + that resolvers are rarely upgraded, and that old nameserver code + never dies. + + Rather than wait years for resolvers to be upgraded through natural + processes before signing zones with unsecure delegations, + addressing this problem with a protocol change will immediately + remove the disincentive for signing zones and allow widespread + deployment of DNSSEC. + +3. Protocol changes + + This document changes the type codes of SIG, KEY, and NXT. This + approach is the cleanest and safest of those discussed above, + largely because the behavior of resolvers that receive unknown type + codes is well understood. This approach has also received the most + testing. + + To avoid operational confusion, it's also necessary to change the + mnemonics for these RRs. DNSKEY will be the replacement for KEY, + with the mnemonic indicating that these keys are not for + application use, per [RFC3445]. RRSIG (Resource Record SIGnature) + will replace SIG, and NSEC (Next SECure) will replace NXT. These + new types completely replace the old types, except that SIG(0) + [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY. + + The new types will have exactly the same syntax and semantics as + specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for + the following: + + 1) Consistent with [RFC3597], domain names embedded in + RRSIG and NSEC RRs MUST NOT be compressed, + + 2) Embedded domain names in RRSIG and NSEC RRs are not downcased + for purposes of DNSSEC canonical form and ordering nor for + equality comparison, and + + 3) An RRSIG with a type-covered field of zero has undefined + semantics. The meaning of such a resource record may only be + defined by IETF Standards Action. + + If a resolver receives the old types, it SHOULD treat them as + unknown RRs and SHOULD NOT assign any special meaning to them or + give them any special treatment. It MUST NOT use them for DNSSEC + validations or other DNS operational decision making. For example, + a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to + validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, + they MUST NOT receive special treatment. As an example, if a SIG + is included in a signed zone, there MUST be an RRSIG for it. + Authoritative servers may wish to give error messages when loading + zones containing SIG or NXT records (KEY records may be included + for SIG(0) or TKEY). + + As a clarification to previous documents, some positive responses, + particularly wildcard proofs and unsecure referrals, will contain + NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as + negative answers merely because they contain an NSEC. + +4. IANA Considerations + +4.1 DNS Resource Record Types + + This document updates the IANA registry for DNS Resource Record + Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and + DNSKEY RRs, respectively. + + Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and + TKEY [RFC2930] use only. + + Type 30 (NXT) should be marked as Obsolete. + +4.2 DNS Security Algorithm Numbers + + To allow zone signing (DNSSEC) and transaction security mechanisms + (SIG(0) and TKEY) to use different sets of algorithms, the existing + "DNS Security Algorithm Numbers" registry is modified to include + the applicability of each algorithm. Specifically, two new columns + are added to the registry, showing whether each algorithm may be + used for zone signing, transaction security mechanisms, or both. + Only algorithms usable for zone signing may be used in DNSKEY, + RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG + may be used in SIG and KEY RRs. + + All currently defined algorithms remain usable for transaction + security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private + algorithms (types 253 and 254) may be used for zone signing. Note + that the registry does not contain the requirement level of each + algorithm, only whether or not an algorithm may be used for the + given purposes. For example, RSA/MD5, while allowed for + transaction security mechanisms, is NOT RECOMMENDED, per RFC3110. + + Additionally, the presentation format algorithm mnemonics from + RFC2535 Section 7 are added to the registry. This document assigns + RSA/SHA-1 the mnemonic RSASHA1. + + As before, assignment of new algorithms in this registry requires + IETF Standards Action. Additionally, modification of algorithm + mnemonics or applicability requires IETF Standards Action. + Documents defining a new algorithm must address the applicability + of the algorithm and should assign a presentation mnemonic to the + algorithm. + +4.3 DNSKEY Flags + + Like the KEY resource record, DNSKEY contains a 16-bit flags field. + This document creates a new registry for the DNSKEY flags field. + + Initially, this registry only contains an assignment for bit 7 (the + ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF + Standards Action. + +4.4 DNSKEY Protocol Octet + + Like the KEY resource record, DNSKEY contains an eight bit protocol + field. The only defined value for this field is 3 (DNSSEC). No + other values are allowed, hence no IANA registry is needed for this + field. + +5. Security Considerations + + The changes introduced here do not materially affect security. + The implications of trying to use both new and legacy types + together are not well understood, and attempts to do so would + probably lead to unintended and dangerous results. + + Changing type codes will leave code paths in legacy resolvers that + are never exercised. Unexercised code paths are a frequent source + of security holes, largely because those code paths do not get + frequent scrutiny. + + Doing nothing, as described in section 2.5, will slow DNSSEC + deployment. While this does not decrease security, it also fails + to increase it. + +6. Normative references + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [DS] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15.txt, work in + progress, June 2003. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures + (SIG(0)s)", RFC 2931, September 2000. + + [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", RFC 2930, September 2000. + + [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name + System (DNS)", RFC 2436, March 1999. + + [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the + Domain Name System (DNS)", RFC 2539, March 1999. + + [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the + Domain Name System (DNS)", RFC 3110, May 2001. + +7. Informative References + + [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, + RFC 2929, September 2000. + + [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. + +8. Acknowledgments + + The changes introduced here and the analysis of alternatives had + many contributors. With apologies to anyone overlooked, those + include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed + Lewis, Bill Manning, and Suzanne Woolf. + + Thanks to Jakob Schlyter and Mark Andrews for identifying the + incompatibility described in section 1.2. + + In addition to the above, the author would like to thank Scott + Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive + comments. + +9. Author's Address + + Samuel Weiler + SPARTA, Inc. + 7075 Samuel Morse Drive + Columbia, MD 21046 + USA + weiler@tislabs.com + diff --git a/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt new file mode 100644 index 0000000000..8097d63455 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt @@ -0,0 +1,1401 @@ + + +DNS Extensions R. Arends +Internet-Draft Telematica Instituut +Expires: August 16, 2004 R. Austein + ISC + M. Larson + VeriSign + D. Massey + USC/ISI + S. Rose + NIST + February 16, 2004 + + + DNS Security Introduction and Requirements + draft-ietf-dnsext-dnssec-intro-09 + +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 16, 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 August 16, 2004 [Page 1] + +Internet-Draft DNSSEC Introduction and Requirements February 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 . . . . . . . . . . . . . . 7 + 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 7 + 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 8 + 4. Services Not Provided by DNS Security . . . . . . . . . . . . 10 + 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 11 + 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 12 + 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 7.1 TTL values vs. RRSIG validity period . . . . . . . . . . . . . 13 + 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 13 + 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 14 + 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 15 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + Normative References . . . . . . . . . . . . . . . . . . . . . 20 + Informative References . . . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 + Intellectual Property and Copyright Statements . . . . . . . . 24 + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 2] + +Internet-Draft DNSSEC Introduction and Requirements February 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 9. Section 3 and Section 4 describe the + capabilities and limitations of the security extensions in greater + detail. Section 5, Section 6, Section 7, and Section 8 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], 3226 [RFC3226], and 3445 + [RFC3445], as well as several works in progress: "Redefinition of the + AD bit" [RFC3655], "Legacy Resolver Compatibility for Delegation + Signer" [I-D.ietf-dnsext-dnssec-2535typecode-change], and "Delegation + Signer Resource Record" [RFC3658]. This document set also updates, + but does not obsolete, RFCs 1034 [RFC1034], 1035 [RFC1035], 2136 + [RFC2136], 2181 [RFC2181], 2308 [RFC2308] and 3597 [RFC3597]. + + 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 August 16, 2004 [Page 3] + +Internet-Draft DNSSEC Introduction and Requirements February 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 which 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 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 which 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 preconfigured to know + about at least one public key. This preconfigured data is usually + either the public key itself or a hash of the key as found in the + DS RR. 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 key has been signed + by another key which the resolver has verified. Note that the + resolver must always be guided by local policy when deciding + whether to authenticate a new key, even if the local policy is + simply to authenticate any new 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). + + 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 with the island's public key + + + +Arends, et al. Expires August 16, 2004 [Page 4] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + + in its delegating parent zone (see + [I-D.ietf-dnsext-dnssec-records]). An island of security is served + by a security-aware nameserver 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 zone + key can be authenticated by some trusted means out of band from + the DNS protocol. + + key signing key: An authentication key which is used to sign one or + more other authentication keys for a given zone. Typically, a key + signing key will sign a zone signing key, which in turn 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. Key signing keys are discussed in more + detail in [I-D.ietf-dnsext-keyrr-key-signing-flag]. See also: 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]) which 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. + + 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". + + + +Arends, et al. Expires August 16, 2004 [Page 5] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + + 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 which is not + "security-aware". + + signed zone: A zone whose RRsets are signed and which contains + properly constructed DNSKEY, RRSIG, NSEC and (optionally) DS + records. + + unsigned zone: A zone which is not signed. + + validating security-aware stub resolver: A security-aware resolver + which operates sends queries in recursive mode but which performs + signature validation on its own rather than just blindly trusting + a friendly security-aware recursive name server. See also: + security-aware stub resolver, non-validating security-aware stub + resolver. + + validating stub resolver: A less tedious term for a validating + security-aware stub resolver. + + zone signing key: An authentication key which is used to sign a zone. + See key signing key, above. Typically a zone signing key will be + part of the same DNSKEY RRset as the key signing key which signs + it, but 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. + See also: key signing key. + + + + +Arends, et al. Expires August 16, 2004 [Page 6] + +Internet-Draft DNSSEC Introduction and Requirements February 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 the key preconfigured 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 preconfigured 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 must have been preconfigured into the + + + +Arends, et al. Expires August 16, 2004 [Page 7] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + + resolver or must have been learned and verified previously. + Therefore, the resolver must be configured with at least one public + key or hash of a public key: if the preconfigured key is a zone + signing key, then it will authenticate the associated zone; if the + preconfigured key is a key signing key, it will authenticate a zone + signing key. If the resolver has been preconfigured 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 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 key or keys used by the + delegated child zone to self-sign the DNSKEY RRset at the child + zone's apex. The child zone, in turn, uses one or more of the keys + in this DNSKEY RRset to sign its zone 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 preconfigured knowledge of the public key for the root. Local + policy, however, may also allow a security-aware resolver to use one + or more preconfigured keys (or key hashes) other than the root key, + or may not provide preconfigured knowledge of the root key, or may + prevent the resolver from using particular keys for arbitrary reasons + even if those 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. + +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 + 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 + + + +Arends, et al. Expires August 16, 2004 [Page 8] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + + 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 August 16, 2004 [Page 9] + +Internet-Draft DNSSEC Introduction and Requirements February 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 11 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 August 16, 2004 [Page 10] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +5. 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 authentication key or + a key's DS RR hash 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 August 16, 2004 [Page 11] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +6. 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 an unaugmented 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 which 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 which 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 August 16, 2004 [Page 12] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +7. 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. + +7.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 RRset + that it covers. 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. + +7.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 August 16, 2004 [Page 13] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +8. 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 half of 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. + + 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, so 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 August 16, 2004 [Page 14] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +9. 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] + + 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 of these documents 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 to show 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 August 16, 2004 [Page 15] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +10. 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 August 16, 2004 [Page 16] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +11. Security Considerations + + This document introduces the DNS security extensions and describes + the document set that contains the new security records and DNS + protocol modifications. This document discusses the capabilities and + limitations of these extensions. The extensions provide data origin + authentication and data integrity using digital signatures over + resource record sets. + + 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 August 16, 2004 [Page 17] + +Internet-Draft DNSSEC Introduction and Requirements February 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 August 16, 2004 [Page 18] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +12. 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, Sam Weiler, and Brian + Wellington. + + No doubt the above is an incomplete list. We apologize to anyone we + left out. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 19] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +Normative References + + [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. + + [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-07 (work in progress), + February 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-05 (work in + progress), February 2004. + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 20] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + +Informative References + + [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. + + [I-D.ietf-dnsext-dns-threats] + Atkins, D. and R. Austein, "Threat Analysis Of The Domain + Name System", draft-ietf-dnsext-dns-threats-05 (work in + progress), November 2003. + + [I-D.ietf-dnsext-dnssec-2535typecode-change] + Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06 + + + +Arends, et al. Expires August 16, 2004 [Page 21] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + + (work in progress), December 2003. + + [I-D.ietf-dnsext-keyrr-key-signing-flag] + Kolkman, O., Schlyter, J. and E. Lewis, "KEY RR Secure + Entry Point Flag", + draft-ietf-dnsext-keyrr-key-signing-flag-12 (work in + progress), December 2003. + + +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 + + + + + + +Arends, et al. Expires August 16, 2004 [Page 22] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + + 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 August 16, 2004 [Page 23] + +Internet-Draft DNSSEC Introduction and Requirements February 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 August 16, 2004 [Page 24] + +Internet-Draft DNSSEC Introduction and Requirements February 2004 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 25] + + diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt new file mode 100644 index 0000000000..6bffb70423 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt @@ -0,0 +1,560 @@ + +DNS Extensions O. Kolkman +Internet-Draft RIPE NCC +Expires: June 17, 2004 J. Schlyter + + E. Lewis + ARIN + December 18, 2003 + + + DNSKEY RR Secure Entry Point Flag + draft-ietf-dnsext-keyrr-key-signing-flag-12 + +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 June 17, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + With the Delegation Signer (DS) resource record the concept of a + public key acting as a secure entry point has been introduced. During + exchanges of public keys with the parent there is a need to + differentiate secure entry point keys from other public keys in the + DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is + defined to indicate that DNSKEY is to be used as a secure entry + point. The flag bit is intended to assist in operational procedures + to correctly generate DS resource records, or to indicate what + DNSKEYs are intended for static configuration. The flag bit is not to + + + +Kolkman, et al. Expires June 17, 2004 [Page 1] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + be used in the DNS verification protocol. This document updates RFC + 2535 and RFC 3445. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4 + 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5 + 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Internationalization Considerations . . . . . . . . . . . . . . 6 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . . . 7 + Informative References . . . . . . . . . . . . . . . . . . . . . 7 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . . 9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 2] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + +1. Introduction + + "All keys are equal but some keys are more equal than others" [6] + + With the definition of the Delegation Signer Resource Record (DS RR) + [5] it has become important to differentiate between the keys in the + DNSKEY RR set that are (to be) pointed to by parental DS RRs and the + other keys in the DNSKEY RR set. We refer to these public keys as + Secure Entry Point (SEP) keys. A SEP key either used to generate a + DS RR or is distributed to resolvers that use the key as the root of + a trusted subtree[3]. + + In early deployment tests, the use of two (kinds of) key pairs for + each zone has been prevalent. For one kind of key pair the private + key is used to sign just the zone's DNSKEY resource record (RR) set. + Its public key is intended to be referenced by a DS RR at the parent + or configured statically in a resolver. The private key of the other + kind of key pair is used to sign the rest of the zone's data sets. + The former key pair is called a key-signing key (KSK) and the latter + is called a zone-signing key (ZSK). In practice there have been + usually one of each kind of key pair, but there will be multiples of + each at times. + + It should be noted that division of keys pairs into KSK's and ZSK's + is not mandatory in any definition of DNSSEC, not even with the + introduction of the DS RR. But, in testing, this distinction has + been helpful when designing key roll over (key super-cession) + schemes. Given that the distinction has proven helpful, the labels + KSK and ZSK have begun to stick. + + There is a need to differentiate the public keys for the key pairs + that are used for key signing from keys that are not used key signing + (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to + be sent for generating DS RRs, which DNSKEYs are to be distributed to + resolvers, and which keys are fed to the signer application at the + appropriate time. + + In other words, the SEP bit provides an in-band method to communicate + a DNSKEY RR's intended use to third parties. As an example we present + 3 use cases in which the bit is useful: + + The parent is a registry, the parent and the child use secured DNS + queries and responses, with a preexisting trust-relation, or plain + DNS over a secured channel to exchange the child's DNSKEY RR + sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset + the SEP bit can be used to isolate the DNSKEYs for which a DS RR + needs to be created. + + + + +Kolkman, et al. Expires June 17, 2004 [Page 3] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + An administrator has configured a DNSKEY as root for a trusted + subtree into security aware resolver. Using a special purpose tool + that queries for the KEY RRs from that domain's apex, the + administrator will be able to notice the roll over of the trusted + anchor by a change of the subset of KEY RRs with the DS flag set. + + A signer might use the SEP bit on the public key to determine + which private key to use to exclusively sign the DNSKEY RRset and + which private key to use to sign the other RRsets in the zone. + + As demonstrated in the above examples it is important to be able to + differentiate the SEP keys from the other keys in a DNSKEY RR set in + the flow between signer and (parental) key-collector and in the flow + between the signer and the resolver configuration. The SEP flag is to + be of no interest to the flow between the verifier and the + authoritative data store. + + The reason for the term "SEP" is a result of the observation that the + distinction between KSK and ZSK key pairs is made by the signer, a + key pair could be used as both a KSK and a ZSK at the same time. To + be clear, the term SEP was coined to lessen the confusion caused by + the overlap. ( Once this label was applied, it had the side effect of + removing the temptation to have both a KSK flag bit and a ZSK flag + bit.) + + The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in RFC2119 [1]. + +2. The Secure Entry Point (SEP) Flag + + + 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 |S| protocol | algorithm | + | |E| | | + | |P| | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + DNSKEY RR Format + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 4] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + This document assigns the 15'th bit in the flags field as the secure + entry point (SEP) bit. If the the bit is set to 1 the key is + intended to be used as secure entry point key. One SHOULD NOT assign + special meaning to the key if the bit is set to 0. Operators can + recognize the secure entry point key by the even or odd-ness of the + decimal representation of the flag field. + +3. DNSSEC Protocol Changes + + The bit MUST NOT be used during the resolving and verification + process. The SEP flag is only used to provide a hint about the + different administrative properties of the key and therefore the use + of the SEP flag does not change the DNS resolution protocol or the + resolution process. + +4. Operational Guidelines + + The SEP bit is set by the key-pair-generator and MAY be used by the + zone signer to decide whether the public part of the key pair is to + be prepared for input to a DS RR generation function. The SEP bit is + recommended to be set (to 1) whenever the public key of the key pair + will be distributed to the parent zone to build the authentication + chain or if the public key is to be distributed for static + configuration in verifiers. + + When a key pair is created, the operator needs to indicate whether + the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within + the data that is used to compute the 'key tag field' in the SIG RR, + changing the SEP bit will change the identity of the key within DNS. + In other words, once a key is used to generate signatures, the + setting of the SEP bit is to remain constant. If not, a verifier will + not be able to find the relevant KEY RR. + + When signing a zone, it is intended that the key(s) with the SEP bit + set (if such keys exist) are used to sign the KEY RR set of the zone. + The same key can be used to sign the rest of the zone data too. It + is conceivable that not all keys with a SEP bit set will sign the + DNSKEY RR set, such keys might be pending retirement or not yet in + use. + + When verifying a RR set, the SEP bit is not intended to play a role. + How the key is used by the verifier is not intended to be a + consideration at key creation time. + + Although the SEP flag provides a hint on which public key is to be + used as trusted root, administrators can choose to ignore the fact + that a DNSKEY has its SEP bit set or not when configuring a trusted + root for their resolvers. + + + +Kolkman, et al. Expires June 17, 2004 [Page 5] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + Using the SEP flag a key roll over can be automated. The parent can + use an existing trust relation to verify DNSKEY RR sets in which a + new DNSKEY RR with the SEP flag appears. + +5. Security Considerations + + As stated in Section 3 the flag is not to be used in the resolution + protocol or to determine the security status of a key. The flag is to + be used for administrative purposes only. + + No trust in a key should be inferred from this flag - trust MUST be + inferred from an existing chain of trust or an out-of-band exchange. + + Since this flag might be used for automating public key exchanges, we + think the following consideration is in place. + + Automated mechanisms for roll over of the DS RR might be vulnerable + to a class of replay attacks. This might happen after a public key + exchange where a DNSKEY RR set, containing two DNSKEY RRs with the + SEP flag set, is sent to the parent. The parent verifies the DNSKEY + RR set with the existing trust relation and creates the new DS RR + from the DNSKEY RR that the current DS RR is not pointing to. This + key exchange might be replayed. Parents are encouraged to implement a + replay defense. A simple defense can be based on a registry of keys + that have been used to generate DS RRs during the most recent roll + over. These same considerations apply to entities that configure keys + in resolvers. + +6. IANA Considerations + + The flag bits in the DNSKEY RR are assigned by IETF consensus and + registered in the DNSKEY Flags registry (created by [4]). This + document assigns the 15th bit in the DNSKEY RR as the Secure Entry + Point (SEP) bit. + +7. Internationalization Considerations + + Although SEP is a popular acronym in many different languages, there + are no internationalization considerations. + +8. Acknowledgments + + The ideas documented in this document are inspired by communications + we had with numerous people and ideas published by other folk. Among + others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, + Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler + have contributed ideas and provided feedback. + + + + +Kolkman, et al. Expires June 17, 2004 [Page 6] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + This document saw the light during a workshop on DNSSEC operations + hosted by USC/ISI in August 2002. + +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] Lewis, E., "DNS Security Extension Clarification on Zone + Status", RFC 3090, March 2001. + + [4] Weiler, S., "Legacy Resolver Compatibility for Delegation + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work + in progress), October 2003. + +Informative References + + [5] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15 (work in progress), June + 2003. + + [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy + Story", ISBN 0151002177 (50th anniversary edition), April 1996. + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Jakob Schlyter + Karl Gustavsgatan 15 + Goteborg SE-411 25 + Sweden + + EMail: jakob@schlyter.se + + + + +Kolkman, et al. Expires June 17, 2004 [Page 7] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + Edward P. Lewis + ARIN + 3635 Concorde Parkway Suite 200 + Chantilly, VA 20151 + US + + Phone: +1 703 227 9854 + EMail: edlewis@arin.net + URI: http://www.arin.net/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman, et al. Expires June 17, 2004 [Page 8] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + +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 (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 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, et al. Expires June 17, 2004 [Page 9] + +Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003 + + + 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, et al. Expires June 17, 2004 [Page 10] + + diff --git a/doc/draft/draft-ietf-dnsext-mdns-29.txt b/doc/draft/draft-ietf-dnsext-mdns-29.txt new file mode 100644 index 0000000000..1a51b690d3 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-mdns-29.txt @@ -0,0 +1,1555 @@ + + +DNSEXT Working Group Levon Esibov +INTERNET-DRAFT Bernard Aboba +Category: Standards Track Dave Thaler + Microsoft +20 January 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 20 January 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 ....................... 13 + 2.8 DNS TTL ......................................... 14 + 2.9 Use of the authority and additional sections .... 14 +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 ............................... 20 + 5.1 Scope restriction ............................... 20 + 5.2 Usage restriction ............................... 21 + 5.3 Cache and port separation ....................... 22 + 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 20 January 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 20 January 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 20 January 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 20 January 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 20 January 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 20 January 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 20 January 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 20 January 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 20 January 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 SHOULD 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 MAY be responded to with a UDP response containing +an empty answer section and the TC bit set, so as to require the sender +to resend the query using TCP. + +If an ICMP "Time Exceeded" message is received in response to a unicast +UDP query, or 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). The UDP sender receiving an ICMP "Time Exceeded" message +SHOULD verify that the ICMP error payload contains a valid LLMNR query +packet, which matches a query that is currently in progress, so as to +guard against a potential Denial of Service (DoS) attack. If a match +cannot be made, then the sender relies on the retransmission and timeout +behavior described in Section 2.7. + +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 + + + +Esibov, Aboba & Thaler Standards Track [Page 11] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +discarded. + +In composing LLMNR queries, the sender MUST set the Hop Limit field in +the IPv6 header and the TTL field in IPv4 header of the response to one +(1). Even 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. Therefore setting the IPv6 Hop Limit +or IPv4 TTL field to one provides an additional precaution against +leakage of LLMNR queries. + +In composing a response to an LLMNR query, the responder MUST set the +Hop Limit field in the IPv6 header and the TTL field in IPv4 header of +the response to one (1). This is done so as to prevent the use of LLMNR +for denial of service attacks across the Internet. + +Section 2.4 discusses use of TCP for LLMNR queries and responses. 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 SYN-ACK from the responder. + +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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 12] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +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 +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) to 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). + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 13] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +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 +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 + + + +Esibov, Aboba & Thaler Standards Track [Page 14] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +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. + +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 + + + +Esibov, Aboba & Thaler Standards Track [Page 15] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +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 +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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 16] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +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: + +[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 that an association has occurred + with a wireless base station and that any required authentication + has completed) + +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 + + + +Esibov, Aboba & Thaler Standards Track [Page 17] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +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. +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 + + + +Esibov, Aboba & Thaler Standards Track [Page 18] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +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, +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 + + + +Esibov, Aboba & Thaler Standards Track [Page 19] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +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. + +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 queries sent to a link-scope +multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6) +fields to one (1) on both queries and responses. + +A TTL of one (1) was chosen so as to limit the likelihood that LLMNR can +be used to launch denial of service attacks. For example, were the TTL +of an LLMNR Response to be set to a value larger than one (1), an +attacker could send a large volume of queries from a spoofed source +address, causing an off-link target to be deluged with responses. + + + +Esibov, Aboba & Thaler Standards Track [Page 20] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +Utilizing a TTL of one (1) in LLMNR responses ensures that they will not +be forwarded off-link. 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. + +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. + + + +Esibov, Aboba & Thaler Standards Track [Page 21] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +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 +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. + + + + +Esibov, Aboba & Thaler Standards Track [Page 22] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +[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. + +[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. + + + +Esibov, Aboba & Thaler Standards Track [Page 23] + + + + + +INTERNET-DRAFT LLMNR 20 January 2004 + + +[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. + +[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-10.txt, October + 2003. + +[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 20 January 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 20 January 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 +August 4, 2004. + + + + + + + + + + + + + + + + + +Esibov, Aboba & Thaler Standards Track [Page 26] + diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt new file mode 100644 index 0000000000..e9943015e4 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt @@ -0,0 +1,1120 @@ + + +DNS Operations M. Larson +Internet-Draft P. Barber +Expires: August 16, 2004 VeriSign + February 16, 2004 + + + Observed DNS Resolution Misbehavior + draft-ietf-dnsop-bad-dns-res-02 + +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 16, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This Internet-Draft describes DNS name server and resolver behavior + that results in a significant query volume sent to the root and + top-level domain (TLD) name servers. In some cases we recommend + minor additions to the DNS protocol specification and corresponding + changes in name server implementations to alleviate these unnecessary + queries. The recommendations made in this document are a direct + byproduct of observation and analysis of abnormal query traffic + patterns seen at two of the thirteen root name servers and all + thirteen com/net TLD name servers. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + + + +Larson & Barber Expires August 16, 2004 [Page 1] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + document are to be interpreted as described in RFC 2119 [1]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Observed name server misbehavior . . . . . . . . . . . . . 4 + 2.1 Aggressive requerying for delegation information . . . . . 4 + 2.1.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2 Repeated queries to lame servers . . . . . . . . . . . . . 5 + 2.2.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 6 + 2.3 Inability to follow multiple levels of out-of-zone glue . 6 + 2.3.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 7 + 2.4 Aggressive retransmission when fetching glue . . . . . . . 7 + 2.4.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 + 2.5 Aggressive retransmission behind firewalls . . . . . . . . 8 + 2.5.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 8 + 2.6 Misconfigured NS records . . . . . . . . . . . . . . . . . 9 + 2.6.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 10 + 2.7 Name server records with zero TTL . . . . . . . . . . . . 10 + 2.7.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 + 2.8 Unnecessary dynamic update messages . . . . . . . . . . . 11 + 2.8.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 11 + 2.9 Queries for domain names resembling IP addresses . . . . . 12 + 2.9.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 12 + 2.10 Misdirected recursive queries . . . . . . . . . . . . . . 12 + 2.10.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 + 2.11 Suboptimal name server selection algorithm . . . . . . . . 13 + 2.11.1 Recommendation . . . . . . . . . . . . . . . . . . . . . . 13 + 3. IANA considerations . . . . . . . . . . . . . . . . . . . 15 + 4. Security considerations . . . . . . . . . . . . . . . . . 16 + 5. Internationalization considerations . . . . . . . . . . . 17 + Normative References . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18 + Intellectual Property and Copyright Statements . . . . . . 19 + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 2] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +1. Introduction + + Observation of query traffic received by two root name servers and + the thirteen com/net TLD name servers has revealed that a large + proportion of the total traffic often consists of "requeries". A + requery is the same question () asked + repeatedly at an unexpectedly high rate. We have observed requeries + from both a single IP address and multiple IP addresses. + + By analyzing requery events we have found that the cause of the + duplicate traffic is almost always a deficient name server, stub + resolver and/or application implementation combined with an + operational anomaly. The implementation deficiencies we have + identified to date include well-intentioned recovery attempts gone + awry, insufficient caching of failures, early abort when multiple + levels of glue records must be followed, and aggressive retry by stub + resolvers and/or applications. Anomalies that we have seen trigger + requery events include lame delegations, unusual glue records, and + anything that makes all authoritative name servers for a zone + unreachable (DoS attacks, crashes, maintenance, routing failures, + congestion, etc.). + + In the following sections, we provide a detailed explanation of the + observed behavior and recommend changes that will reduce the requery + rate. Some of the changes recommended affect the core DNS protocol + specification, described principally in RFC 1034 [2], RFC 1035 [3] + and RFC 2181 [4]. + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 3] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +2. Observed name server misbehavior + +2.1 Aggressive requerying for delegation information + + There can be times when every name server in a zone's NS RRset is + unreachable (e.g., during a network outage), unavailable (e.g., the + name server process is not running on the server host) or + misconfigured (e.g., the name server is not authoritative for the + given zone, also known as "lame"). Consider a recursive name server + that attempts to resolve a query for a domain name in such a zone and + discovers that none of the zone's name servers can provide an answer. + We have observed a recursive name server implementation that then + verifies the zone's NS RRset in its cache by querying for the zone's + delegation information: it sends a query for the zone's NS RRset to + one of the parent zone's name servers. + + For example, suppose that "example.com" has the following NS RRset: + + example.com. IN NS ns1.example.com. + example.com. IN NS ns2.example.com. + + Upon receipt of a query for "www.example.com" and assuming that + neither "ns1.example.com" nor "ns2.example.com" can provide an + answer, this recursive name server implementation immediately queries + a "com" zone name server for the "example.com" NS RRset to verify it + has the proper delegation information. This name server + implementation performs this query to a zone's parent zone for each + recursive query it receives that fails because of a completely + unresponsive set of name servers for the target zone. Consider the + effect when a popular zone experiences a catastrophic failure of all + its name servers: now every recursive query for domain names in that + zone sent to this name server implementation results in a query to + the failed zone's parent name servers. On one occasion when several + dozen popular zones became unreachable, the query load on the com/net + name servers increased by 50%. + + We believe this verification query is not reasonable. Consider the + circumstances: When a recursive name server is resolving a query for + a domain name in a zone it has not previously searched, it uses the + list of name servers in the referral from the target zone's parent. + If on its first attempt to search the target zone, none of the name + servers in the referral is reachable, a verification query to the + parent is pointless: this query to the parent would come so quickly + on the heels of the referral that it would be almost certain to + contain the same list of name servers. The chance of discovering any + new information is slim. + + The other possibility is that the recursive name server successfully + + + +Larson & Barber Expires August 16, 2004 [Page 4] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + contacts one of the target zone's name servers and then caches the NS + RRset from the authority section of a response, the proper behavior + according to section 5.4.1 of RFC 2181 [4], because the NS RRset from + the target zone is more trustworthy than delegation information from + the parent zone. If, while processing a subsequent recursive query, + the recursing name server discovers that none of the name servers + specified in the cached NS RRset is available or authoritative, + querying the parent would be wrong. An NS RRset from the parent zone + would now be less trustworthy than data already in the cache. + + For this query of the parent zone to be useful, the target zone's + entire set of name servers would have to change AND the former set of + name servers would have to be deconfigured and/or decommissioned AND + the delegation information in the parent zone would have to be + updated with the new set of name servers, all within the TTL of the + target zone's NS RRset. We believe this scenario is uncommon: + administrative best practices dictate that changes to a zone's set of + name servers happen gradually, with servers that are removed from the + NS RRset left authoritative for the zone as long as possible. The + scenarios that we can envision that would benefit from the parent + requery behavior do not outweigh its damaging effects. + +2.1.1 Recommendation + + Name servers offering recursion MUST NOT send a query for the NS + RRset of a non-responsive zone to any of the name servers for that + zone's parent zone. For the purposes of this injunction, a + non-responsive zone is defined as a zone for which every name server + listed in the zone's NS RRset: + + 1. is not authoritative for the zone (i.e., lame), or, + + 2. returns a server failure response (RCODE=2), or, + + 3. is dead or unreachable according to section 7.2 of RFC 2308 [5]. + + +2.2 Repeated queries to lame servers + + Section 2.1 describes a catastrophic failure: when every name server + for a zone is unable to provide an answer for one reason or another. + A more common occurrence is a subset of a zone's name servers being + unavailable or misconfigured. Different failure modes have different + expected durations. Some symptoms indicate problems that are + potentially transient: various types of ICMP unreachable messages + because a name server process is not running or a host or network is + unreachable, or a complete lack of a response to a query. Such + responses could be the result of a host rebooting or temporary + + + +Larson & Barber Expires August 16, 2004 [Page 5] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + outages; these events don't necessarily require any human + intervention and can be reasonably expected to be temporary. + + Other symptoms clearly indicate a condition requiring human + intervention, such as lame server: if a name server is misconfigured + and not authoritative for a zone delegated to it, it is reasonable to + assume that this condition has potential to last longer than + unreachability or unresponsiveness. Consequently, repeated queries + to known lame servers are not useful. In this case of a condition + with potential to persist for a long time, a better practice would be + to maintain a list of known lame servers and avoid querying them + repeatedly in a short interval. + +2.2.1 Recommendation + + Recursive name servers SHOULD cache name servers that they discover + are not authoritative for zones delegated to them (i.e. lame + servers). Lame servers MUST be cached against the specific query + tuple . Zone name can be + derived from the owner name of the NS record that was referenced to + query the name server that was discovered to be lame. + Implementations that perform lame server caching MUST refrain from + sending queries to known lame servers based on a time interval from + when the server is discovered to be lame. A minimum interval of + thirty minutes is RECOMMENDED. + +2.3 Inability to follow multiple levels of out-of-zone glue + + Some recursive name server implementations are unable to follow more + than one level of out-of-zone glue. For example, consider the + following delegations: + + foo.example. IN NS ns1.example.com. + foo.example. IN NS ns2.example.com. + + example.com. IN NS ns1.test.example.net. + example.com. IN NS ns2.test.example.net. + + test.example.net. IN NS ns1.test.example.net. + test.example.net. IN NS ns2.test.example.net. + + A name server processing a recursive query for "www.foo.example" must + follow two levels of indirection, first obtaining address records for + "ns1.test.example.net" and/or "ns2.test.example.net" in order to + obtain address records for "ns1.example.com" and/or "ns2.example.com" + in order to query those name servers for the address records of + "www.foo.example". While this situation may appear contrived, we + have seen multiple similar occurrences and expect more as new generic + + + +Larson & Barber Expires August 16, 2004 [Page 6] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + top-level domains (gTLDs) become active. We anticipate many zones in + the new gTLDs will use name servers in other gTLDs, increasing the + amount of inter-zone glue. + +2.3.1 Recommendation + + Clearly constructing a delegation that relies on multiple levels of + out-of-zone glue is not a good administrative practice. This issue + could be mitigated with an operational injunction in an RFC to + refrain from construction of such delegations. In our opinion the + practice is widespread enough to merit clarifications to the DNS + protocol specification to permit it on a limited basis. + + Name servers offering recursion SHOULD be able to handle at least + three levels of indirection resulting from out-of-zone glue. + +2.4 Aggressive retransmission when fetching glue + + When an authoritative name server responds with a referral, it + includes NS records in the authority section of the response. + According to the algorithm in section 4.3.2 of RFC 1034 [2], the name + server should also "put whatever addresses are available into the + additional section, using glue RRs if the addresses are not available + from authoritative data or the cache." Some name server + implementations take this address inclusion a step further with a + feature called "glue fetching". A name server that implements glue + fetching attempts to include A records for every NS record in the + authority section. If necessary, the name server issues multiple + queries of its own to obtain any missing A records. + + Problems with glue fetching can arise in the context of + "authoritative-only" name servers, which only serve authoritative + data and ignore requests for recursion. Such a server will not + generate any queries of its own. Instead it answers non-recursive + queries from resolvers looking for information in zones it serves. + With glue fetching enabled, however, an authoritative server will + generate queries whenever it needs to look up an unknown address + record to complete the additional section of a response. + + We have observed situations where a glue-fetching name server can + send queries that reach other name servers, but apparently is + prevented from receiving the responses. For example, perhaps the + name server is authoritative-only and therefore its administrators + expect it to receive only queries. Perhaps unaware of glue fetching + and presuming that the name server will generate no queries, its + administrators place the name server behind a network device that + prevents it from receiving responses. If this is the case, all + glue-fetching queries will go answered. + + + +Larson & Barber Expires August 16, 2004 [Page 7] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + We have observed name server implementations that retry excessively + when glue-fetching queries are unanswered. A single com/net name + server has received hundreds of queries per second from a single name + server. Judging from the specific queries received and based on + additional analysis, we believe these queries result from overly + aggressive glue fetching. + +2.4.1 Recommendation + + Implementers whose name servers support glue fetching should take + care to avoid sending queries at excessive rates. Implementations + should support throttling logic to detect when queries are sent but + no responses are received. + +2.5 Aggressive retransmission behind firewalls + + A common occurrence and one of the largest sources of repeated + queries at the com/net and root name servers appears to result from + resolvers behind misconfigured firewalls. In this situation, a + recursive name server is apparently allowed to send queries through a + firewall to other name servers, but not receive the responses. The + result is more queries than necessary because of retransmission, all + of which are useless because the responses are never received. Just + as with the glue-fetching scenario described in Section 2.4, the + queries are sometimes sent at excessive rates. To make matters + worse, sometimes the responses, sent in reply to legitimate queries, + trigger an alarm on the originator's intrusion detection system. We + are frequently contacted by administrators responding to such alarms + who believe our name servers are attacking their systems. + + Not only do some resolvers in this situation retransmit queries at an + excessive rate, but they continue to do so for days or even weeks. + This scenario could result from an organization with multiple + recursive name servers, only a subset of whose traffic is improperly + filtered in this manner. Stub resolvers in the organization could be + configured to query multiple name servers. Consider the case where a + stub resolver queries a filtered name server first. This name server + sends one or more queries whose replies are filtered, so it can't + respond to the stub resolver, which times out. The resolver + retransmits to a name server that is able to provide an answer. + Since resolution ultimately succeeds the underlying problem might not + be recognized or corrected. A popular stub resolver has a very + aggressive retransmission schedule, including simultaneous queries to + multiple name servers, which could explain how such a situation could + persist without being detected. + +2.5.1 Recommendation + + + + +Larson & Barber Expires August 16, 2004 [Page 8] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + The most obvious recommendation is that administrators should take + care not to place recursive name servers behind a firewall that + prohibits queries to pass through but not the resulting replies. + + Name servers should take care to avoid sending queries at excessive + rates. Implementations should support throttling logic to detect + when queries are sent but no responses are received. + +2.6 Misconfigured NS records + + Sometimes a zone administrator forgets to add the trailing dot on the + domain names in the RDATA of a zone's NS records. Consider this + fragment of the zone file for "example.com": + + $ORIGIN example.com. + example.com. 3600 IN NS ns1.example.com ; Note missing + example.com. 3600 IN NS ns2.example.com ; trailing dots + + The zone's authoritative servers will parse the NS RDATA as + "ns1.example.com.example.com" and "ns2.example.com.example.com" and + return NS records with this incorrect RDATA in responses, including + typically the authority section of every response containing records + from the "example.com" zone. + + Now consider a typical sequence of queries. A recursive name server + attempting to resolve A records for "www.example.com" with no cached + information for this zone will query a "com" authoritative server. + The "com" server responds with a referral to the "example.com" zone, + consisting of NS records with valid RDATA and associated glue + records. (This example assumes that the "example.com" zone + information is correct in the "com" zone.) The recursive name server + caches the NS RRset from the "com" server and follows the referral by + querying one of the "example.com" authoritative servers. This server + responds with the "www.example.com" A record in the answer section + and, typically, the "example.com" NS records in the authority section + and, if space in the message remains, glue A records in the + additional section. According to Section 5.4 of RFC 2181 [4], NS + records in the authority section of an authoritative answer are more + trustworthy than NS records from the authority section of a + non-authoritative answer. Thus the "example.com" NS RRset just + received from the "example.com" authoritative server displaces the + "example.com" NS RRset received moments ago from the "com" + authoritative server. + + But the "example.com" zone contains the erroneous NS RRset as shown + in the example above. Subsequent queries for names in "example.com" + will cause the server to attempt to use the incorrect NS records and + so the server will try to resolve the nonexistent names + + + +Larson & Barber Expires August 16, 2004 [Page 9] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + "ns1.example.com.example.com" and "ns2.example.com.example.com". In + this example, since all of the zone's name servers are named in the + zone itself (i.e., "ns1.example.com.example.com" and + "ns2.example.com.example.com" both end in "example.com") and all are + bogus, the recursive server cannot reach any "example.com" name + servers. Therefore attempts to resolve these names result in A + record queries to the "com' authoritative servers. Queries for such + obviously bogus glue A records occur frequently at the com/net name + servers. + +2.6.1 Recommendation + + An authoritative server can detect this situation. A trailing dot + missing from an NS record's RDATA always results by definition in a + name server name that is in the zone. But any in-zone name server + should have a corresponding glue A record also in the zone. An + authoritative name server should report an error when a zone's NS + record references an in-zone name server without a corresponding glue + A record. + +2.7 Name server records with zero TTL + + Sometimes a popular com/net subdomain's zone is configured with a TTL + of zero on the zone's NS records, which prohibits these records from + being cached and will result in a higher query volume to the zone's + authoritative servers. The zone's administrator should understand + the consequences of such a configuration and provision resources + accordingly. A zero TTL on the zone's NS RRset, however, carries + additional consequences beyond the zone itself: if a recursive name + server cannot cache a zone's NS records because of a zero TTL, it + will be forced to query that zone's parent's name servers each time + it resolves a name in the zone. The com/net authoritative servers do + see an increased query load when a popular com/net subdomain's zone + is configured with a TTL of zero on the zone's NS records. + + A zero TTL on an RRset expected to change frequently is extreme but + permissible. A zone's NS RRset is a special case, however, because + changes to it must be coordinated with the zone's parent. In most + zone parent/child relationships we are aware of, there is typically + some delay involved in effecting changes. Further, changes to the + set of a zone's authoritative name servers (and therefore to the + zone's NS RRset) are typically relatively rare: providing reliable + authoritative service requires a reasonably stable set of servers. + Therefore an extremely low or zero TTL on a zone's NS RRset rarely + makes sense, except in anticipation of an upcoming change. In this + case, when the zone's administrator has planned a change and does not + want recursive name servers throughout the Internet to cache the NS + RRset for a long period of time, a low TTL is reasonable. + + + +Larson & Barber Expires August 16, 2004 [Page 10] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +2.7.1 Recommendation + + Because of the additional load placed on a zone's parent's + authoritative servers imposed by a zero TTL on a zone's NS RRset, + under such circumstances authoritative name servers should issue a + warning when loading a zone or refuse to load the zone altogether. + +2.8 Unnecessary dynamic update messages + + The UPDATE message specified in RFC 2136 [6] allows an authorized + agent to update a zone's data on an authoritative name server using a + DNS message sent over the network. Consider the case of an agent + desiring to add a particular resource record. Because of zone cuts, + the agent does not necessarily know the proper zone to which the + record should be added. The dynamic update process requires that the + agent determine the appropriate zone so the UPDATE message can be + sent to one of the zone's authoritative servers (typically the + primary master as specified in the zone's SOA MNAME field). + + The appropriate zone to update is the closest enclosing zone, which + is the lowest zone in the name space. The closest enclosing zone + cannot be determined only by inspecting the domain name of the record + to be updated, since zone cuts can occur anywhere. One way to + determine the closest enclosing zone involves working up the name + space tree and sending repeated UPDATE messages until success. For + example, consider an agent attempting to add an A record with the + name "foo.bar.example.com". The agent could first attempt to update + the "foo.bar.example.com" zone. If the attempt failed, the update + could be directed to the "bar.example.com" zone, then the + "example.com" zone, then the "com" zone, and finally the root zone. + + A popular dynamic agent follows this algorithm. The result is many + UPDATE messages received by the root name servers, the com/net + authoritative servers, and presumably other TLD authoritative + servers. A reasonable question is why the algorithm proceeds with + sending updates all the way to TLD and root name servers. In + enterprise DNS architectures with an "internal root" design, there + could conceivably be private, non-public TLD or root zones that would + be the appropriate target for a dynamic update. However, we question + if designing an algorithm to accommodate these limited cases is worth + the load it places on the public DNS in the form of unnecessary + UPDATE messages. + +2.8.1 Recommendation + + Dynamic update agents should not attempt to send UPDATE messages to + authoritative servers for TLD zones or the root zone by default. If + this functionality is supported, it should be require specific action + + + +Larson & Barber Expires August 16, 2004 [Page 11] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + by a user to be enabled. + +2.9 Queries for domain names resembling IP addresses + + The root name servers receive a significant number of A record + queries where the qname is an IP address. The source of these + queries is unknown. It could be attributed to situations where a + user believes an application will accept either a domain name or an + IP address in a given configuration option. The user enters an IP + address, but the application assumes any input is a domain name and + attempts to resolve it, resulting in an A record lookup. There could + also be applications that produce such queries in a misguided attempt + to reverse map IP addresses. + + These queries result in Name Error (RCODE=3) responses. A recursive + name server can negatively cache such responses, but each response + requires a separate cache entry, i.e., a negative cache entry for the + domain name "192.0.2.1" does not prevent a subsequent query for the + domain name "192.0.2.2". + +2.9.1 Recommendation + + It would be desirable for the root name servers not to have to answer + these queries: they unnecessarily consume CPU resources and network + bandwidth. One possibility is for recursive name server + implementations to produce the Name Error response directly. We + suggest that implementors consider the option of synthesizing Name + Error responses at the recursive name server. The server could claim + authority for synthesized TLD zones corresponding to the first octet + of every possible IP address, e.g. 1., 2., through 255. This + behavior could be configurable in the (probably unlikely) event that + numeric TLDs are ever put into use. + + Another option is to delegate these numeric TLDs from the root zone + to a separate set of servers to absorb the traffic. The "blackhole + servers" used by the the AS 112 Project [8], which are currently + delegated the in-addr.arpa zones corresponding to RFC 1918 [7] + private use address space, would be a possible choice to receive + these delegations. + +2.10 Misdirected recursive queries + + The root name servers receive a significant number of recursive + queries (i.e., queries with the RD bit set in the header). Since + none of the root servers offer recursion, the servers' response in + such a situation ignores the request for recursion and the response + probably does not contain the data the querier anticipated. Some of + these queries result from users configuring stub resolvers to query a + + + +Larson & Barber Expires August 16, 2004 [Page 12] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + root server. (This situation is not hypothetical: we have received + complaints from users when this configuration does not work as + hoped.) Of course, users should not direct stub resolvers to use name + servers that do not offer recursion, but we are not aware of any stub + resolver implementation that offers any feedback to the user when so + configured, aside from simply "not working". + +2.10.1 Recommendation + + When the IP address of a (supposedly) recursive name server is + configured in a stub resolver using an interactive user interface, + the resolver could send a test query to verify that the server + supports recursion (i.e., the response has the RA bit set in the + header). The user could be immediately notified if the server is + non-recursive. + + The stub resolver could also report an error, either through a user + interface or in a log file, if the queried server does not support + recursion. Error reporting should be throttled to avoid a + notification or log message for every response from a non-recursive + server. + +2.11 Suboptimal name server selection algorithm + + An entire document could be devoted to the topic of problems with + different implementations of the recursive resolution algorithm. The + entire process of recursion is woefully underspecified, requiring + each implementor to design an algorithm. Sometimes implementors make + poor design choices that could be avoided if a suggested algorithm + and best practices were documented, but that is a topic for another + document. + + Some deficiencies cause significant operational impact and are + therefore worth mentioning here. One of these is name server + selection by a recursive name server. When a recursive name server + wants to contact one of a zone's authoritative name servers, how does + it choose from the NS records listed in the zone's NS RRset? If the + selection mechanism is suboptimal, queries are not spread evenly + among a zone's authoritative servers. The details of the selection + mechanism are up to the implementor, but we offer some suggestions. + +2.11.1 Recommendation + + This list is not conclusive, but reflects the changes that would + produce the most impact in terms of reducing disproportionate query + load among a zone's authoritative servers. I.e., these changes would + help spread the query load evenly. + + + + +Larson & Barber Expires August 16, 2004 [Page 13] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + o Do not make assumptions based on NS RRset order: all NS RRs should + be treated equally. (In the case of the "com" zone, for example, + most of the root servers return the NS record for + "a.gtld-servers.net" first in the authority section of referrals. + As a result, this server receives disproportionately more traffic + than the other 12 authoritative servers for "com".) + + o Use all NS records in an RRset. (For example, we are aware of + implementations that hard-coded information for a subset of the + root servers.) + + o Maintain state and favor the best-performing of a zone's + authoritative servers. A good definition of performance is + response time. Non-responsive servers can be penalized with an + extremely high response time. + + o Do not lock onto the best-performing of a zone's name servers. A + recursive name server should periodically check the performance of + all of a zone's name servers to adjust its determination of the + best-performing one. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 14] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +3. IANA considerations + + There are no new IANA considerations introduced by this + Internet-Draft. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 15] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +4. Security considerations + + Name server and resolver misbehaviors identical or similar to those + discussed in this document expose the root and TLD name servers to + increased risk of both intentional and unintentional denial of + service. + + We believe that implementation of the recommendations offered in this + document will reduce the amount of unnecessary traffic seen at root + and TLD name servers, thus reducing the opportunity for an attacker + to use such queries to his or her advantage. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 16] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +5. Internationalization considerations + + We do not believe this document introduces any new + internationalization considerations to the DNS protocol + specification. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 17] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + +Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [3] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [4] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + [5] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC + 2308, March 1998. + + [6] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April + 1997. + + [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + + [8] + + +Authors' Addresses + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Piet Barber + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: pbarber@verisign.com + + + + + +Larson & Barber Expires August 16, 2004 [Page 18] + +Internet-Draft Observed DNS Resolution Misbehavior February 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 + + + +Larson & Barber Expires August 16, 2004 [Page 19] + +Internet-Draft Observed DNS Resolution Misbehavior February 2004 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Larson & Barber Expires August 16, 2004 [Page 20] + diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt new file mode 100644 index 0000000000..04addcfb24 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt @@ -0,0 +1,1288 @@ + + +DNSOP O. Kolkman +Internet-Draft RIPE NCC +Expires: March 1, 2004 R. Gieben + NLnet Labs + September 2003 + + + DNSSEC Operational Practices + draft-ietf-dnsop-dnssec-operational-practices-00.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 March 1, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document intends to describe a set of practices for operating a + DNSSEC aware enviroment. Its target audience is zone administrators + who are deploying DNSSEC and need a guide to help them chose sensible + values for DNSSEC parameters. Is also discusses operational matters + like key rollovers, KSK and ZSK considerations and more. + + + + + + + + + +Kolkman & Gieben Expires March 1, 2004 [Page 1] + +Internet-Draft DNSSEC Operational Practices September 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 The use of the term 'key' . . . . . . . . . . . . . . . . . 3 + 2. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1 Time definitions . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2 Time considerations . . . . . . . . . . . . . . . . . . . . 4 + 3. Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1 Motivations for the KSK and ZSK functions . . . . . . . . . 6 + 3.2 Key security considerations . . . . . . . . . . . . . . . . 7 + 3.3 Key rollovers . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.3.1 Zone-signing key rollovers . . . . . . . . . . . . . . . . . 9 + 3.3.2 Key-signing key rollovers . . . . . . . . . . . . . . . . . 12 + 4. Planning for emergency key rollover. . . . . . . . . . . . . 13 + 4.1 KSK compromise . . . . . . . . . . . . . . . . . . . . . . . 13 + 4.2 ZSK compromise . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.3 Compromises of keys anchored in resolvers . . . . . . . . . 14 + 5. Parental policies. . . . . . . . . . . . . . . . . . . . . . 14 + 5.1 Initial key exchanges and parental policies + considerations. . . . . . . . . . . . . . . . . . . . . . . 14 + 5.2 Storing keys so hashes can be regenerated . . . . . . . . . 15 + 5.3 Security lameness checks. . . . . . . . . . . . . . . . . . 15 + 5.4 SIG DS validity period. . . . . . . . . . . . . . . . . . . 15 + 6. Security considerations . . . . . . . . . . . . . . . . . . 16 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 + Normative References . . . . . . . . . . . . . . . . . . . . 16 + Informative References . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 + A. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 17 + B. Zone-signing key rollover howto . . . . . . . . . . . . . . 18 + C. Typographic conventions . . . . . . . . . . . . . . . . . . 19 + D. Document Details and Changes . . . . . . . . . . . . . . . . 20 + D.1 draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . . 22 + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires March 1, 2004 [Page 2] + +Internet-Draft DNSSEC Operational Practices September 2003 + + +1. Introduction + + During workshops and early operational deployment tests, operators + and system administrators gained knowledge about operating DNSSEC + aware DNS services. This document describes these practices. + + The structure of the document is as follows. It starts 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 is 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. Therefore this document + will use the term key rather loosely. Wherever we write that 'a key + is used to sign data' it is assumed that the reader knows that it is + the private part of the key-pair that is used for signing. It is also + assumed that the reader will know that the public part of the + key-pair is published in the DNSKEY resource record and that it is + the public part of a key-pair that is used in key-exchanges. + +2. Time in DNSSEC + + Without DNSSEC all times in DNS are relative. The SOA's refresh, + retry and expiration timers are counters that are being used to + determine the time elapsed after a slave server synced (or tried to + sync) with a master server. The TTL value and the SOA minimum TTL + parameter [6] are used to 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 invalid and the signed data is to be considered BAD. + +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" + + + + + +Kolkman & Gieben Expires March 1, 2004 [Page 3] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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. + + o "Signature publication period" + + Time after which a signature made with a 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 on time T0 and a new signature is + published on 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 to the period between + two consecutive zone signing operations. + + o "Key publication period" + + The period for which the public part of the key is published in + the DNS. The public part of the key can be published in the DNS + while it has not yet been used to sign data. As soon as a + public key is published a brute force attack can be attempted + to recover the private key. Publishing the public key in + advance (and not signing any data with it) does not guard + against this attack. + + [Editor's Note: We don't use this term in the doc yet, is it + needed elsewhere and handy to define here? No:1 Yes:0] + + 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 behavior might become bursty. + + + + + +Kolkman & Gieben Expires March 1, 2004 [Page 4] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + We suggest the TTL on all the RRs in your zone to be at least + an order of magnitude smaller than your signature validity + period. + + o The signature publication period should at least be one maximum + TTL smaller than the signature validity period. + + If a zone is resigned shortly before the end of the signature + validity period this may cause simultaneous expiration of data + from caches which leads to bursty query behavior and increase + the load on authoritative servers. + + o The Minimum zone TTL should be long enough to fetch and verify all + the RRs in the authentication chain. + + 1. During validation, some data may expire before validation + is complete. The validator should be able to keep all the + data, until validation is complete. This applies to all data + in 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. + + 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 at least of the + order 10 minutes to an hour and all the other RRs in your zone + to be at least 30 seconds. These are absolute minimum, we + recommend zone administrators to chose longer ones. + + [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. + + 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 + counted down to zero. It is not possible to fully prevent this + from happening by tweaking the SOA parameters. But the effects + can be minimized if the SOA expiration time is of the same of + + + +Kolkman & Gieben Expires March 1, 2004 [Page 5] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + order of magnitude as or smaller than the signature validity + period. + + When a zone cannot be updated while signatures in that zone + have expired non-secure resolvers will continue to be able to + resolve the data served by the particular slave servers. Only + security aware resolvers that receive data with expired + signatures will experience problems. + + We suggest the SOA expiration timer being approximately one + third or one fourth of the signature validity period. + + We also suggest that operators of nameservers with slave zones + develop watchdogs to be able to spot these upcoming signature + expirations in slave zones, so that appropriate action can be + taken. + + o [Editor's Note: Need examples here] + + +3. Keys + +3.1 Motivations for the KSK and ZSK functions + + Delegation Signer [7] introduced the concept of key-signing and + zone-signing keys.The Key-signing-flag [4] introduced the concept of + a key with the Secure Entry Point flag set; a key that is the first + key from the zone when following an authentication chain. When using + a key-signing key with the SEP flag set (the parent has a DS RR + pointing to that DNSKEY) and when using zone-signing keys without the + SEP flag set (a practice which we recommend ) one can use the + following operational procedures. + + 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 over no + interactions with the parent is needed. This allows for relatively + short "Signature Validity Periods" (order of days). + + The key-signing key (with the SEP flag set) 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 maintainer 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 March 1, 2004 [Page 6] + +Internet-Draft DNSSEC Operational Practices September 2003 + + +3.2 Key security considerations + + In RFC2541 [2] a number of considerations with respect to the + security of keys are described. That document deals with the + generation, lifetime, size and storage of private keys. + + In Section 3 of RFC2541 [2], Eastlake does have some suggestions: 13 + months for long-lived keys and 36 days for transaction keys but + suggestions for key sizes are not made. + + If we read the long-lived key being a key that is used as key-signing + key and transaction keys being zone signing keys, then these + recommendations are good starting points for an operational + procedure. These recommendations will lead to rollovers occurring + frequently enough so that they can become part of 'operational + habits' and the procedure does not have to be reinvented every time a + key is replaced. + + When choosing a 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. + + 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 + + + +Kolkman & Gieben Expires March 1, 2004 [Page 7] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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 + + Suppose you want your key to last 3 years and the current year is + 2003. Add 3 to 2003 equals 2006 and read of the sizes: 1191 for + asymmetric keys and 148 bits for elliptic curve keys. + + Note that adding only a "handful of bits" to the key size will + increase the key's resistance against brute force attacks. + +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 + maintainers who are in the process of rolling their keys have to take + into account that data they have 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 which is + 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 BAD. + 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 BAD. + + 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. + + + + +Kolkman & Gieben Expires March 1, 2004 [Page 8] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + Note that KSK rollovers and ZSK rollovers are different. A zone-key + rollover can be handled in two different way: pre-publish and + [Editors note: ref please] double-sig. 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 the data still in caches can be verified with the + new keysets or the 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.1, the other uses key pre-publication + (Section 3.3.1.2). The pros, cons and recommendations are described + in Section 3.3.1.3. + +3.3.1.1 A double signature zone-signing key rollover + + This section shows how to perform a ZSK key rollover using the double + zone data signature scheme. + + 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) + + + + + + + +Kolkman & Gieben Expires March 1, 2004 [Page 9] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + normal: Version 0 of the zone: DNSKEY 1 is a key-signing key. DNSKEY + 10 is used to sign all the data of the zone, it is the + zone-signing key. + + 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 the 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 the 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". + + To be on the safe side one could make sure that the rollover phase + lasts until the signature expiration time of the data in version 0 of + the zone. But this date could be considerable longer than the Maximum + Zone TTL, making the rollover a lengthly procedure. + + Note that in this example we assumed that the zone did not get + modified during the rollover. New data can be introduced in the zone + as long as it is signed with both keys. + +3.3.1.2 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. We recommend this method because + it has advantages in the case of key compromises. If the old key gets + compromised the new key is already distributed in the DNS. The zone + administrator is then able to quickly switch to the new key and + remove the compromised 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) + + + + +Kolkman & Gieben Expires March 1, 2004 [Page 10] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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 a key-signing key. DNSKEY + 10 is used to sign all the data of the zone, its the zone-signing + key. + + pre-roll: DNSKEY 11 is introduced in the keyset. Note that no + signatures are generated with this key yet, but this will not + prevent 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 on the + keyset. This would boil down 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 that includes 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 a bit by always publishing the + "future" key immediately after the rollover. The scheme would look + like this (we show 2 rollovers); the future key is introduced in + "after" as DNSKEY 12 and again a newer one, numbered 13, in "2nd + after": + + + normal roll after 2nd roll 2nd after + + SOA0 SOA2 SOA3 SOA4 SOA5 + RRSIG10(SOA0) RRSIG11(SOA2) RRSIG11(SOA3) RRSIG12(SOA4) RRSIG12(SOA5) + + + +Kolkman & Gieben Expires March 1, 2004 [Page 11] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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, can immediately be used during an emergency rollover under the + assumption that it was stored in a physically secure manner. + +3.3.1.3 Pros and cons of the schemes + + A double signature rollover: The drawback of this signing scheme is + that during the rollover the number of signatures in your zone + doubles, which may be prohibitive if you have very big zones. An + advantage is that it only requires three steps. + + 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 is useless for + KSKs as explained in Section 3.3. + + +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, size considerations do not apply. + + + normal roll after + + SOA0 SOA1 SOA2 + RRSIG10(SOA0) RRSIG10(SOA1) RRSIG10(SOA2) + + DNSKEY1 DNSKEY1 DNSKEY2 + DNSKEY2 + DNSKEY10 DNSKEY10 DNSKEY10 + + + +Kolkman & Gieben Expires March 1, 2004 [Page 12] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG2(DNSKEY) + RRSIG2 (DNSKEY) + RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG10(DNSKEY) + + +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 has as a + result 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 by 'blackhats' for as long as a valid authentication chain + exists. A authentication chain remains intact for: + + as long as a signature over the compromised key in the + authentication chain is valid, + + as long as a parental DS RR (and signature) points to the + compromised key, + + 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 "blackhat". 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 can not be validated. On the + other hand if the zone administrator chooses to take the path of a + regular roll-over the "blackhat" can spoof data so that it appears to + be valid, note that this kind of attack will usually be localized in + the Internet topology. + + +4.1 KSK compromise + + When the KSK has been compromised the parent must be notified as soon + as possible and through 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. + + + +Kolkman & Gieben Expires March 1, 2004 [Page 13] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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 legitemate 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 + + Mainly 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. One has to take into account though 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 minimizes that problem. + +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 that key is compromised all the resolvers 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 authorization + mechanisms used during a key exchange should be as strong as the + authentication and authorization 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 changes of operator error. A parental DNSKEY + + + +Kolkman & Gieben Expires March 1, 2004 [Page 14] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + download tool can make use of the SEP bit [4] to select the proper + key from a DNSSEC keyset; thereby reducing the change that the wrong + DNSKEY is sent. It can validate the self-signature over a key; + thereby verifying the ownership of the private key material. Besides, + by fetching the DNSKEY from the DNS one can be sure that the child + will not become invisible once the parent indicates the child is + secure by publishing the DS RR. + + Note: the off-band verification is still needed when the keymaterial + is fetched by a tool. The parent can not be sure if the DNSKEY RRs + where not spoofed. + +5.2 Storing keys so hashes can be regenerated + + When designing a registry system one should consider if the DNSKEYs + or the corresponding DSs are stored. Storing DNSKEYs will help during + troubleshooting while the overhead of calculating DS records from + them is minimal. + + Having a 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. + +5.3 Security lameness checks. + + Security lameness is defined as the event that a parent has a DS + Resource Record that points to a non-existing DNSKEY RR. At key + exchange a parent should make sure that the childs 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 marked "BAD". + + Child zones should be very careful removing DNSKEY material, + specifically SEP keys, for which a DS RR exist. + + 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 SIG DS validity period. + + Since the DS can be replayed as long as it has a valid signature a + short signature validity period over the DS minimizes the time a + child is vulnerable in the case of a compromise of the child's KSK. + A signature validity period that is too short introduces the + possibility that a zone is marked BAD 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 weekends show the + need for a DS signature lifetimes longer than 2 days. We recommend + the minimum for a DS signature validity period to be about a few + + + +Kolkman & Gieben Expires March 1, 2004 [Page 15] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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 the order of one week a good + compromise between the operational constraints of the parent and + minimizing 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. + +7. Acknowledgments + + We, the folk mentioned as authors, only acted as editors. Most of the + ideas in this draft where the result of collective efforts during + workshops and discussions and try outs. + + At the risk of forgetting individuals who where the original + contributors of the ideas we like to acknowledge people who where + actively involved in the compilation of this document. In + alphabetical order: Olafur Gudmundsson, Wesley Griffin, Michael + Richardson, Scott Rose, Rick van Rein, Tim McGinnis. + + Kolkman and Gieben take the blame for all mistakes. + +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. + +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 + + + +Kolkman & Gieben Expires March 1, 2004 [Page 16] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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. + + +Authors' Addresses + + Olaf M. Kolkman + RIPE NCC + Singel 256 + Amsterdam 1016 AB + NL + + Phone: +31 20 535 4444 + EMail: olaf@ripe.net + URI: http://www.ripe.net/ + + + Miek Gieben + NLnet Labs + Kruislaan 419 + Amsterdam 1098 VA + NL + + 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 give 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 2 keys, a public key and a private key. The public + keys are published in the DNS by use of the DNSKEY Resource Record + + + +Kolkman & Gieben Expires March 1, 2004 [Page 17] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + (DNSKEY RR). Private keys are supposed to remain private i.e. + should not be exposed to parties not-authorized 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 for exclusively + 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. + + BAD: [Editors Note: a reference here] A RRset in DNSSEC is marked + "bad" when a signature of a RRset does not validate against the + DNSKEY. Even is the key itself was not marked BAD. BAD data is not + cached. + + Singing the Zone File: The term used for the event where an + administrator joyfully signs its zone file while producing melodic + sound patterns. + + +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] + + STEP 0, the preparation: Create two keys and publish them 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 + zonefile created with the current key currently marked as + "active". + + Wait until the expiration time marked in STEP 1 + + + + + + +Kolkman & Gieben Expires March 1, 2004 [Page 18] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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 abreviated to + just: A. + + Signature notation: Signatures are denoted as SIGx(RRset), which + means that RRset is signed with KEYx. + + Zone representation: Using the above notation we have simplify the + representation of a signed zone by leaving out all unneeded + details such as the names and by just representing all data by + "SOAx" + + SOA representation: Soa's are represented as SOA x, 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. + + + +Kolkman & Gieben Expires March 1, 2004 [Page 19] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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. + 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 + + + +Kolkman & Gieben Expires March 1, 2004 [Page 20] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + document is published. + + $Header: /var/cvs/dnssec-key/ + draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.5 2003/10/10 + 09:49:07 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kolkman & Gieben Expires March 1, 2004 [Page 21] + +Internet-Draft DNSSEC Operational Practices September 2003 + + +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 (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 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 March 1, 2004 [Page 22] + +Internet-Draft DNSSEC Operational Practices September 2003 + + + 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 March 1, 2004 [Page 23] + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt new file mode 100644 index 0000000000..280c2f2d9a --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-04.txt @@ -0,0 +1,1233 @@ + + +DNS Operations WG A. Durand +Internet-Draft SUN Microsystems, Inc. +Expires: July 1, 2004 J. Ihren + Autonomica + P. Savola + CSC/FUNET + Jan 2004 + + + Operational Considerations and Issues with IPv6 DNS + draft-ietf-dnsop-ipv6-dns-issues-04.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 July 1, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This memo presents operational considerations and issues with IPv6 + Domain Name System (DNS), including a summary of special IPv6 + addresses, documentation of known DNS implementation misbehaviour, + recommendations and considerations on how to perform DNS naming for + service provisioning and for DNS resolver IPv6 support, + considerations for DNS updates for both the forward and reverse + trees, and miscellaneous issues. This memo is aimed to include a + summary of information about IPv6 DNS considerations for those who + have experience with IPv4 DNS. + + + +Durand, et al. Expires July 1, 2004 [Page 1] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . . . 3 + 1.2 Independence of DNS Transport and DNS Records . . . . . . . . 3 + 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . . . 4 + 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 4 + 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . . . 4 + 2.2 Privacy (RFC3041) Address . . . . . . . . . . . . . . . . . . 4 + 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5 + 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . . . 5 + 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . . . 6 + 4. Recommendations for Service Provisioning using DNS . . . . . . 6 + 4.1 Use of Service Names instead of Node Names . . . . . . . . . . 6 + 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . . . 7 + 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . . . 7 + 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . . . 8 + 4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments . . . . . . 8 + 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . . . 9 + 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 9 + 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . . . 9 + 5.2 Recursive DNS Resolver Discovery . . . . . . . . . . . . . . . 11 + 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . . . 11 + 6. Considerations about Forward DNS Updating . . . . . . . . . . 11 + 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 12 + 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7. Considerations about Reverse DNS Updating . . . . . . . . . . 13 + 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . . . 13 + 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 14 + 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . . . 14 + 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . . . 14 + 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . . . 15 + 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 15 + 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . . . 15 + 8.2 Renumbering Procedures and Applications' Use of DNS . . . . . 15 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + Normative References . . . . . . . . . . . . . . . . . . . . . 16 + Informative References . . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 + A. Site-local Addressing Considerations for DNS . . . . . . . . . 19 + Intellectual Property and Copyright Statements . . . . . . . . 21 + + + + + + + + +Durand, et al. Expires July 1, 2004 [Page 2] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + +1. Introduction + + This memo presents operational considerations and issues with IPv6 + DNS; it is meant to be an extensive summary and a list of pointers + for more information about IPv6 DNS considerations for those with + experience with IPv4 DNS. + + The first section gives a brief overview of how IPv6 addresses and + names are represented in the DNS, how transport protocols and + resource records (don't) relate, and what IPv4/IPv6 name space + fragmentation means and how to avoid it; all of these are described + at more length in other documents. + + The second section summarizes the special IPv6 address types and how + they relate to DNS. The third section describes observed DNS + implementation misbehaviours which have a varying effect on the use + of IPv6 records with DNS. The fourth section lists recommendations + and considerations for provisioning services with DNS. The fifth + section in turn looks at recommendations and considerations about + providing IPv6 support in the resolvers. The sixth and seventh + sections describe considerations with forward and reverse DNS + updates, respectively. The eighth section introduces several + miscellaneous IPv6 issues relating to DNS for which no better place + has been found in this memo. Appendix A looks briefly at the + requirements for site-local addressing. + +1.1 Representing IPv6 Addresses in DNS Records + + In the forward zones, IPv6 addresses are represented using AAAA + records. In the reverse zones, IPv6 address are represented using + PTR records in the nibble format under the ip6.arpa. -tree. See [1] + for more about IPv6 DNS usage, and [2] or [4] for background + information. + + In particular one should note that the use of A6 records, DNAME + records in the reverse tree, or Bitlabels in the reverse tree is not + recommended [2]. + +1.2 Independence of DNS Transport and DNS Records + + DNS has been designed to present a single, globally unique name space + [6]. This property should be maintained, as described here and in + Section 1.3. + + In DNS, the IP version used to transport the queries and responses is + independent of the records being queried: AAAA records can be queried + over IPv4, and A records over IPv6. The DNS servers must not make any + assumptions about what data to return for Answer and Authority + + + +Durand, et al. Expires July 1, 2004 [Page 3] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + sections. + + However, there is some debate whether the addresses in Additional + section could be selected or filtered using hints obtained from which + transport was being used; this has some obvious problems because in + many cases the transport protocol does not correlate with the + requests, and because a "bad" answer is in a way worse than no answer + at all (consider the case where the client is led to believe that a + name received in the additional record does not have any AAAA records + to begin with). + + As stated in [1]: + + The IP protocol version used for querying resource records is + independent of the protocol version of the resource records; e.g., + IPv4 transport can be used to query IPv6 records and vice versa. + + +1.3 Avoiding IPv4/IPv6 Name Space Fragmentation + + To avoid the DNS name space from fragmenting into parts where some + parts of DNS are only visible using IPv4 (or IPv6) transport, the + recommendation is to always keep at least one authoritative server + IPv4-enabled, and to ensure that recursive DNS servers support IPv4. + See DNS IPv6 transport guidelines [3] for more information. + +2. DNS Considerations about Special IPv6 Addresses + + There are a couple of IPv6 address types which are somewhat special; + these are considered here. + +2.1 Limited-scope Addresses + + The IPv6 addressing architecture [5] includes two kinds of local-use + addresses: link-local (fe80::/10) and site-local (fec0::/10). The + site-local addresses are being deprecated [7], and are only discussed + in Appendix A. + + Link-local addresses should never be published in DNS, because they + have only local (to the connected link) significance [8]. + +2.2 Privacy (RFC3041) Address + + Privacy addresses (RFC3041 [9]) use a random number as the interface + identifier. Publishing DNS records relating to such addresses would + defeat the purpose of the mechanism and is not recommended. If + absolutely necessary, a mapping could be made to some + non-identifiable name, as described in [9]. + + + +Durand, et al. Expires July 1, 2004 [Page 4] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + +2.3 6to4 Addresses + + 6to4 [10] specifies an automatic tunneling mechanism which maps a + public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. + Providing reverse DNS delegation path for such addresses is a + challenge. Note that similar difficulties don't surface with the + other automatic tunneling mechanisms (in particular, providing + reverse DNS information for Teredo [11] hosts whose address includes + the UDP port of the NAT binding does not seem reasonable). + + If the reverse DNS population would be desirable (see Section 7.1 for + applicability), there are a number of ways to tackle the delegation + path problem [12], some more applicable than the others. + + The main proposal [13] has been to allocate 2.0.0.2.ip6.arpa. to RIRs + and let them do subdelegations in accordance to the delegations of + the respective IPv4 address space. This has a major practical + drawback: those ISPs and IPv4 address space holders where 6to4 is + being used do not, in general, provide any IPv6 services -- as + otherwise, most people would not have to use 6to4 to begin with -- + and it is improbable that the reverse delegation chain would be + completed either. In most cases, creating such delegation chains + might just lead to latencies caused by lookups for (almost always) + non-existent DNS records. + +3. Observed DNS Implementation Misbehaviour + + Several classes of misbehaviour in DNS servers, load-balancers and + resolvers have been observed. Most of these are rather generic, not + only applicable to IPv6 -- but in some cases, the consequences of + this misbehaviour are extremely severe in IPv6 environments and + deserve to be mentioned. + +3.1 Misbehaviour of DNS Servers and Load-balancers + + There are several classes of misbehaviour in certain DNS servers and + load-balancers which have been noticed and documented [14]: some + implementations silently drop queries for unimplemented DNS records + types, or provide wrong answers to such queries (instead of a proper + negative reply). While typically these issues are not limited to + AAAA records, the problems are aggravated by the fact that AAAA + records are being queried instead of (mainly) A records. + + The problems are serious because when looking up a DNS name, typical + getaddrinfo() implementations, with AF_UNSPEC hint given, first try + to query the AAAA records of the name, and after receiving a + response, query the A records. This is done in a serial fashion -- if + the first query is never responded to (instead of properly returning + + + +Durand, et al. Expires July 1, 2004 [Page 5] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + a negative answer), significant timeouts will occur. + + In consequence, this is an enormous problem for IPv6 deployments, and + in some cases, IPv6 support in the software has even been disabled + due to these problems. + + The solution is to fix or retire those misbehaving implementations, + but that is likely not going to be effective. There are some + possible ways to mitigate the problem, e.g. by performing the lookups + somewhat in parallel and reducing the timeout as long as at least one + answer has been received; but such methods remain to be investigated; + slightly more on this is included in Section 5. + +3.2 Misbehaviour of DNS Resolvers + + Several classes of misbehaviour have also been noticed in DNS + resolvers [15]. However, these do not seem to directly impair IPv6 + use, and are only referred to for completeness. + +4. Recommendations for Service Provisioning using DNS + + When names are added in the DNS to facilitate a service, there are + several general guidelines to consider to be able to do it as + smoothly as possible. + +4.1 Use of Service Names instead of Node Names + + When a node includes multiple services, one should keep them + logically separate in the DNS. This can be done by the use of + service names instead of node names (or, "hostnames"). + + For example, assume a node named "pobox.example.com" provides both + SMTP and IMAP service. Instead of configuring the MX records to + point at "pobox.example.com", and configuring the mail clients to + look up the mail via IMAP from "pobox.example.com", one should use + e.g. "smtp.example.com" for SMTP (for both message submission and + mail relaying between SMTP servers) and "imap.example.com" for IMAP. + Note that in the specific case of SMTP relaying, the server itself + must typically also be configured to know all its names to ensure + loops do not occur. DNS can provide a layer of indirection between + service names and where the service actually is, and using which + addresses. + + This is a good practice with IPv4 as well, because it provides more + flexibility and enables easier migration of services from one host to + another. A specific reason why this is relevant for IPv6 is that the + different services may have a different level of IPv6 support -- that + is, one node providing multiple services might want to enable just + + + +Durand, et al. Expires July 1, 2004 [Page 6] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + one service to be IPv6-visible while keeping some others as + IPv4-only. Using service names enables more flexibility with + different IP versions as well. + +4.2 Separate vs the Same Service Names for IPv4 and IPv6 + + The service naming can be achieved in basically two ways: when a + service is named "service.example.com" for IPv4, the IPv6-enabled + service could be either added to "service.example.com", or added + separately to a sub-domain, like, "service.ipv6.example.com". + + Both methods have different characteristics. Using a sub-domain + allows for easier service piloting, minimizing the disturbance to the + "regular" users of IPv4 service; however, the service would not be + used without explicitly asking for it (or, within a restricted + network, modifying the DNS search path) -- so it will not actually be + used that much. Using the same service name is the "long-term" + solution, but may degrade performance for those clients whose IPv6 + performance is lower than IPv4, or does not work as well (see the + next subsection for more). + + In most cases, it makes sense to pilot or test a service using + separate service names, and move to the use of the same name when + confident enough that the service level will not degrade for the + users unaware of IPv6. + +4.3 Adding the Records Only when Fully IPv6-enabled + + The recommendation is that AAAA records for a service should not be + added to the DNS until all of following are true: + + 1. The address is assigned to the interface on the node. + + 2. The address is configured on the interface. + + 3. The interface is on a link which is connected to the IPv6 + infrastructure. + + In addition, if the AAAA record is added for the node, instead of + service as recommended, all the services of the node should be + IPv6-enabled prior to adding the resource record. + + For example, if an IPv6 node is isolated from an IPv6 perspective + (e.g., it is not connected to IPv6 Internet) constraint #3 would mean + that it should not have an address in the DNS. + + Consider the case of two dual-stack nodes, which both have IPv6 + enabled, but the server does not have (global) IPv6 connectivity. As + + + +Durand, et al. Expires July 1, 2004 [Page 7] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + the client looks up the server's name, only A records are returned + (if the recommendations above are followed), and no IPv6 + communication, which would have been unsuccessful, is even attempted. + + The issues are not always so black-and-white. Usually it's important + if the service offered using both protocols is of roughly equal + quality, using the appropriate metrics for the service (e.g., + latency, throughput, low packet loss, general reliability, etc.) -- + this is typically very important especially for interactive or + real-time services. In many cases, the quality of IPv6 connectivity + is not yet equal to that of IPv4, at least globally -- this has to be + taken into consideration when enabling services [16]. + +4.4 The Use of TTL for IPv4 and IPv6 RRs + + The behaviour of DNS caching when different TTL values are used for + different records of the same name requires explicit discussion. For + example, let's consider a part of a zone: + + example.com. 300 IN MX foo.example.com. + foo.example.com. 300 IN A 192.0.2.1 + foo.example.com. 100 IN AAAA 2001:db8::1 + + Now, when a caching resolver asks for the MX record of example.com, + it gets both A and AAAA records of foo.example.com. Then, after 100 + seconds, the AAAA record is removed from the cache because its TTL + expired. Now, subsequent queries only result in the cache returning + the A record; after 200 seconds the A record is purged as well. So, + in this particular case, there is a window of 200 seconds when + incomplete information is returned from the cache. + + Therefore, when the same name refers to both A and AAAA records, + these records should have the same TTL. Otherwise, the caches may + return incomplete information about the queried names. More issues + with caching and A/AAAA records is presented in the next section. + +4.5 Behaviour of Glue in Mixed IPv4/IPv6 Environments + + In the previous section, we discussed the effect of impartial data + returned from the caches when the TTLs are not kept the same. Now, + we present another problem highlighted in the mixed IPv4/IPv6 + environments. + + Consider the case where the query is so long or the number of the + additional ("glue") records is so high that the response must either + be truncated (leading to a retry with TCP) or some of the additional + data removed from the reply. Further, resource record sets are never + "broken up", so if a name has 4 A records and 5 AAAA records, you can + + + +Durand, et al. Expires July 1, 2004 [Page 8] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + either return all 9, all 4 A records, all 5 AAAA records or nothing. + + In the case of too much additional data, it might be tempting to not + return the AAAA records if the transport for DNS query was IPv4, or + not return the A records, if the transport was IPv6. However, this + breaks the model of independence of DNS transport and resource + records, as noted in Section 1.2. + + This temptation would have significant problems in multiple areas. + Remember that often the end-node, which will be using the records, is + not the same one as the node requesting them from the authorative DNS + server (or even a caching resolver). So, whichever version the + requestor ("the middleman") uses makes no difference to the ultimate + user of the records. This might result in e.g., inappropriately + returning A records to an IPv6-only node, going through a + translation, or opening up another IP-level session (e.g., a PDP + context [31]). + + The problem of too much additional data seems to be an operational + one: the zone administrator entering too many records which will be + returned either truncated or impartial to the users. A protocol fix + for this is using EDNS0 [32] to signal the capacity for larger UDP + packet sizes, pushing up the relevant threshold. The operational fix + for this is having the DNS server implementations return a warning + when the administrators create the zones which would result in too + much additional data being returned. + +4.6 IPv6 Transport Guidelines for DNS Servers + + As described in Section 1.3 and [3], there should continue to be at + least one authorative IPv4 DNS server for every zone, even if the + zone has only IPv6 records. (Note that obviously, having more servers + with robust connectivity would be preferable, but this is the minimum + recommendation; also see [17].) + +5. Recommendations for DNS Resolver IPv6 Support + + When IPv6 is enabled on a node, there are several things to consider + to ensure that the process is as smooth as possible. + +5.1 DNS Lookups May Query IPv6 Records Prematurely + + The system library that implements the getaddrinfo() function for + looking up names is a critical piece when considering the robustness + of enabling IPv6; it may come in basically three flavours: + + 1. The system library does not know whether IPv6 has been enabled in + the kernel of the operating system: it may start looking up AAAA + + + +Durand, et al. Expires July 1, 2004 [Page 9] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + records with getaddrinfo() and AF_UNSPEC hint when the system is + upgraded to a system library version which supports IPv6. + + 2. The system library might start to perform IPv6 queries with + getaddrinfo() only when IPv6 has been enabled in the kernel. + However, this does not guarantee that there exists any useful + IPv6 connectivity (e.g., the node could be isolated from the + other IPv6 networks, only having link-local addresses). + + 3. The system library might implement a toggle which would apply + some heuristics to the "IPv6-readiness" of the node before + starting to perform queries; for example, it could check whether + only link-local IPv6 address(es) exists, or if at least one + global IPv6 address exists. + + First, let us consider generic implications of unnecessary queries + for AAAA records: when looking up all the records in the DNS, AAAA + records are typically tried first, and then A records. These are + done in serial, and the A query is not performed until a response is + received to the AAAA query. Considering the misbehaviour of DNS + servers and load-balancers, as described in Section 3.1, the look-up + delay for AAAA may incur additional unnecessary latency, and + introduce a component of unreliability. + + One option here could be to do the queries partially in parallel; for + example, if the final response to the AAAA query is not received in + 0.5 seconds, start performing the A query while waiting for the + result (immediate parallelism might be unoptimal without information + sharing between the look-up threads, as that would probably lead to + duplicate non-cached delegation chain lookups). + + An additional concern is the address selection, which may, in some + circumstances, prefer AAAA records over A records, even when the node + does not have any IPv6 connectivity [18]. In some cases, the + implementation may attempt to connect or send a datagram on a + physical link [19], incurring very long protocol timeouts, instead of + quickly failing back to IPv4. + + Now, we can consider the issues specific to each of the three + possibilities: + + In the first case, the node performs a number of completely useless + DNS lookups as it will not be able to use the returned AAAA records + anyway. (The only exception is where the application desires to know + what's in the DNS, but not use the result for communication.) One + should be able to disable these unnecessary queries, for both latency + and reliability reasons. However, as IPv6 has not been enabled, the + connections to IPv6 addresses fail immediately, and if the + + + +Durand, et al. Expires July 1, 2004 [Page 10] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + application is programmed properly, the application can fall + gracefully back to IPv4 [20]. + + The second case is similar to the first, except it happens to a + smaller set of nodes when IPv6 has been enabled but connectivity has + not been provided yet; similar considerations apply, with the + exception that IPv6 records, when returned, will be actually tried + first which may typically lead to long timeouts. + + The third case is a bit more complex: optimizing away the DNS lookups + with only link-locals is probably safe (but may be desirable with + different lookup services which getaddrinfo() may support), as the + link-locals are typically automatically generated when IPv6 is + enabled, and do not indicate any form of IPv6 connectivity. That + is, performing DNS lookups only when a non-link-local address has + been configured on any interface could be beneficial -- this would be + an indication that either the address has been configured either from + a router advertisement, DHCPv6, or manually. Each would indicate at + least some form of IPv6 connectivity, even though there would not be + guarantees of it. + + These issues should be analyzed at more depth, and the fixes found + consensus on, perhaps in a separate document. + +5.2 Recursive DNS Resolver Discovery + + Recursive IPv6 DNS resolver discovery is a subject of active debate + at the moment: the main proposed mechanisms include the use of + well-known addresses [21], the use of Router Advertisements to convey + the information [22], and using DHCPv6 (or the stateless subset of it + [23]) for DNS resolver configuration. No consensus has been reached + yet. + + Note that IPv6 DNS resolver discovery, while an important topic, is + not required for dual-stack nodes in dual-stack networks: IPv6 DNS + records can very well be queried over IPv4 as well. + +5.3 IPv6 Transport Guidelines for Resolvers + + As described in Section 1.3 and [3], the recursive resolvers should + be IPv4-only or dual-stack to be able to reach any IPv4-only DNS + server. Note that this requirement is also fulfilled by an IPv6-only + stub resolver pointing to a dual-stack recursive DNS resolver. + +6. Considerations about Forward DNS Updating + + While the topic how to enable updating the forward DNS, i.e., the + mapping from names to the correct new addresses, is not specific to + + + +Durand, et al. Expires July 1, 2004 [Page 11] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + IPv6, it bears thinking about especially due to adding Stateless + Address Autoconfiguration [24] to the mix. + + Typically forward DNS updates are more manageable than doing them in + the reverse DNS, because the updater can, typically, be assumed to + "own" a certain DNS name -- and we can create a form of security + association with the DNS name and the node allowed to update it to + point to a new address. + + A more complex form of DNS updates -- adding a whole new name to a + DNS zone, instead of updating an existing name -- is considered + out-of-scope: this is not an IPv6-specific problem, and one still + being explored. + +6.1 Manual or Custom DNS Updates + + The DNS mappings can be maintained by hand, in a semi-automatic + fashion or by running non-standardized protocols. These are not + considered at more length in this memo. + +6.2 Dynamic DNS + + Dynamic DNS updates (DDNS) [25][26] is a standardized mechanism for + dynamically updating the DNS. It works equally well with stateless + address autoconfiguration (SLAAC), DHCPv6 or manual address + configuration. The only (minor) twist is that with SLAAC, the DNS + server cannot tie the authentication of the user to the IP address, + and stronger mechanisms must be used. Actually, relying on IP + addresses for Dynamic DNS is rather insecure at best, so this is + probably not a significant problem (but requires that the + authorization keying will be explicitly configured). + + Note that with DHCP, it is also possible that the DHCP server updates + the DNS, not the host. The host might only indicate in the DHCP + exchange which hostname it would prefer, and the DHCP server would + make the appropriate updates. Nonetheless, while this makes setting + up a secure channel between the updater and the DNS server easier, it + does not help much with "content" security, i.e., whether the + hostname was acceptable -- if the DNS server does not include + policies, they must be included in the DHCP server (e.g., a regular + host should not be able to state that its name is "www.example.com"). + + The nodes must somehow be configured with the information about the + servers where they will attempt to update their addresses, sufficient + security material for authenticating themselves to the server, and + the hostname they will be updating. Unless otherwise configured, the + first could be obtained by looking up the authorative name servers + for the hostname; the second must be configured explicitly unless one + + + +Durand, et al. Expires July 1, 2004 [Page 12] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + chooses to trust the IP address -based authentication (not a good + idea); and lastly, the nodename is typically pre-configured somehow + on the node, e.g. at install time. + + Care should be observed when updating the addresses not to use longer + TTLs for addresses than are preferred lifetimes for the + autoconfigured addresses, so that if the node is renumbered in a + managed fashion, the amount of stale DNS information is kept to the + minimum. Actually, the DNS TTL should be much shorter (e.g., a half + or a third) than the lifetime of an address; that way, the node can + start lowering the DNS TTL if it seems like the address has not be + renewed/refreshed in a while. Some discussion on how to manage the + DNS TTL is included in [28]. + +7. Considerations about Reverse DNS Updating + + Forward DNS updating is rather straightforward; reverse DNS is + significantly trickier especially with certain mechanisms. However, + first it makes sense to look at the applicability of reverse DNS in + the first place. + +7.1 Applicability of Reverse DNS + + Today, some applications use reverse DNS to either look up some hints + about the topological information associated with an address (e.g. + resolving web server access logs), or as a weak form of a security + check, to get a feel whether the user's network administrator has + "authorized" the use of the address (on the premises that adding a + reverse record for an address would signal some form of + authorization). + + One additional, maybe slightly more useful usage is ensuring the + reverse and forward DNS contents match and correspond to a configured + name or domain. As a security check, it is typically accompanied by + other mechanisms, such as a user/password login; the main purpose of + the DNS check is to weed out the majority of unauthorized users, and + if someone managed to bypass the checks, he would still need to + authenticate "properly". + + It is not clear whether it makes sense to require or recommend that + reverse DNS records be updated. In many cases, it would just make + more sense to use proper mechanisms for security (or topological + information lookup) in the first place. At minimum, the applications + which use it as a generic authorization (in the sense that a record + exists at all) should be modified as soon as possible to avoid such + lookups completely. + + The applicability is discussed at more length in [29]. + + + +Durand, et al. Expires July 1, 2004 [Page 13] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + +7.2 Manual or Custom DNS Updates + + Reverse DNS can of course be updated using manual or custom methods. + These are not further described here, except for one special case. + + One way to deploy reverse DNS would be to use wildcard records, for + example, by configuring one name for a subnet (/64) or a site (/48). + Naturally, such a name could not be verified from the forward DNS, + but would at least provide some form of "topological information" or + "weak authorization" if that is really considered to be useful. Note + that this is not actually updating the DNS as such, as the whole + point is to avoid DNS updates completely by manually configuring a + generic name. + +7.3 DDNS with Stateless Address Autoconfiguration + + Dynamic DNS with SLAAC is a bit complicated, but manageable with a + rather low form of security with some implementation. + + Every node on a link must then be allowed to insert its own reverse + DNS record in the reverse zone. However, in the typical case, there + can be no stronger form of authentication between the nodes and the + server than the source IP address (the user may roam to other + administrative domains as well, requiring updates to foreign DNS + servers), which might make attacks more lucrative. + + Moreover, the reverse zones must be cleaned up by some janitorial + process: the node does not typically know a priori that it will be + disconnected, and cannot send a DNS update using the correct source + address to remove a record. + + To insert or update the record, the node must discover the DNS server + to send the update to somehow, similar to as discussed in Section + 6.2. One way to automate this is looking up the DNS server + authoritative for the IP address being updated, but the security + material (unless the IP address -based authorization is trusted) must + also be established by some other means. + +7.4 DDNS with DHCP + + With DHCP, the reverse DNS name is typically already inserted to the + DNS that reflects to the name (e.g., "dhcp-67.example.com"). This is + pre-configured, and requires no updating. + + If a more explicit control is required, similar considerations as + with SLAAC apply, except for the fact that typically one must update + a reverse DNS record instead of inserting one -- due to a denser + address assignment policy -- and updating a record seems like a + + + +Durand, et al. Expires July 1, 2004 [Page 14] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + slightly more difficult thing to secure. + + Note that when using DHCP, either the host or the DHCP server could + perform the DNS updates; see the implications in Section 6.2. + +7.5 DDNS with Dynamic Prefix Delegation + + In cases where more than one address is being used and updated, one + should consider where the updated server resides. That is, whether + the prefixes have been delegated to a node in the local site, or + whether they reside elsewhere, e.g., at the ISP. The reverse DNS + updates are typically easier to manage if they can be done within a + single administrative entity -- and therefore, if a reverse DNS + delegation has been made, it may be easier to enable reverse DNS at + the site, e.g. by a wildcard record, or by some DNS update mechanism. + +8. Miscellaneous DNS Considerations + + This section describes miscellaneous considerations about DNS which + seem related to IPv6, for which no better place has been found in + this document. + +8.1 NAT-PT with DNS-ALG + + NAT-PT [27] DNS-ALG is a critical component (unless something + replacing that functionality is specified) which mangles A records to + look like AAAA records to the IPv6-only nodes. Numerous problems have + been identified with DNS-ALG [30]. + +8.2 Renumbering Procedures and Applications' Use of DNS + + One of the most difficult problems of systematic IP address + renumbering procedures [28] is that an application which looks up a + DNS name disregards information such as TTL, and uses the result + obtained from DNS as long as it happens to be stored in the memory of + the application. For applications which run for a long time, this + could be days, weeks or even months; some applications may be clever + enough to organize the data structures and functions in such a manner + that look-ups get refreshed now and then. + + While the issue appears to have a clear solution, "fix the + applications", practically this is not reasonable immediate advice; + the TTL information is not typically available in the APIs and + libraries (so, the advice becomes "fix the applications, APIs and + libraries"), and a lot more analysis is needed on how to practically + go about to achieve the ultimate goal of avoiding using the names + longer than expected. + + + + +Durand, et al. Expires July 1, 2004 [Page 15] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + +9. Acknowledgements + + Some recommendations (Section 4.3, Section 5.1) about IPv6 service + provisioning were moved here from [33] by Erik Nordmark and Bob + Gilligan. Havard Eidnes and Michael Patton provided useful feedback + and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark + Andrews helped in clarifying the issues regarding additional data and + the use of TTL. + +10. Security Considerations + + This document reviews the operational procedures for IPv6 DNS + operations and does not have security considerations in itself. + + However, it is worth noting that in particular with Dynamic DNS + Updates, security models based on the source address validation are + very weak and cannot be recommended. On the other hand, it should be + noted that setting up an authorization mechanism (e.g., a shared + secret, or public-private keys) between a node and the DNS server has + to be done manually, and may require quite a bit of time and + expertise. + + To re-emphasize which was already stated, reverse DNS checks provide + very weak security at best, and the only (questionable) + security-related use for them may be in conjunction with other + mechanisms when authenticating a user. + +Normative References + + [1] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October 2003. + + [2] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, + "Representing Internet Protocol version 6 (IPv6) Addresses in + the Domain Name System (DNS)", RFC 3363, August 2002. + + [3] Durand, A. and J. Ihren, "DNS IPv6 transport operational + guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-01 (work + in progress), October 2003. + +Informative References + + [4] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August + 2001. + + [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + + + +Durand, et al. Expires July 1, 2004 [Page 16] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + [6] Internet Architecture Board, "IAB Technical Comment on the + Unique DNS Root", RFC 2826, May 2000. + + [7] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", draft-ietf-ipv6-deprecate-site-local-02 (work in + progress), November 2003. + + [8] Hazel, P., "IP Addresses that should never appear in the public + DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in + progress), February 2002. + + [9] Narten, T. and R. Draves, "Privacy Extensions for Stateless + Address Autoconfiguration in IPv6", RFC 3041, January 2001. + + [10] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via + IPv4 Clouds", RFC 3056, February 2001. + + [11] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", + draft-huitema-v6ops-teredo-00 (work in progress), June 2003. + + [12] Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in + progress), October 2002. + + [13] Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa", + draft-ymbk-6to4-arpa-delegation-00 (work in progress), February + 2003. + + [14] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS + Queries for IPv6 Addresses", + draft-morishita-dnsop-misbehavior-against-aaaa-00 (work in + progress), June 2003. + + [15] Larson, M. and P. Barber, "Observed DNS Resolution + Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in + progress), June 2003. + + [16] Savola, P., "Moving from 6bone to IPv6 Internet", + draft-savola-v6ops-6bone-mess-01 (work in progress), November + 2002. + + [17] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and + Operation of Secondary DNS Servers", BCP 16, RFC 2182, July + 1997. + + [18] Roy, S., "Dual Stack IPv6 on by Default", + draft-ietf-v6ops-v6onbydefault-00 (work in progress), October + 2003. + + + + +Durand, et al. Expires July 1, 2004 [Page 17] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + [19] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered + Harmful", draft-ietf-v6ops-onlinkassumption-00 (work in + progress), October 2003. + + [20] Shin, M., "Application Aspects of IPv6 Transition", + draft-ietf-v6ops-application-transition-00 (work in progress), + December 2003. + + [21] Ohta, M., "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-00 (work in progress), July 2003. + + [22] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement", + draft-jeong-dnsop-ipv6-dns-discovery-00 (work in progress), + July 2003. + + [23] Droms, R., "Stateless DHCP Service for IPv6", + draft-ietf-dhc-dhcpv6-stateless-04 (work in progress), January + 2004. + + [24] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [25] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [26] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [27] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - + Protocol Translation (NAT-PT)", RFC 2766, February 2000. + + [28] Baker, F., "Procedures for Renumbering an IPv6 Network without + a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in + progress), October 2003. + + [29] Senie, D., "Requiring DNS IN-ADDR Mapping", + draft-ietf-dnsop-inaddr-required-03 (work in progress), March + 2002. + + [30] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", + draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress), + February 2003. + + [31] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", + draft-ietf-v6ops-3gpp-analysis-07 (work in progress), October + 2003. + + + + +Durand, et al. Expires July 1, 2004 [Page 18] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + [32] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + + [33] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for + IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in + progress), October 2003. + + +Authors' Addresses + + Alain Durand + SUN Microsystems, Inc. + 17 Network circle UMPL17-202 + Menlo Park, CA 94025 + USA + + EMail: Alain.Durand@sun.com + + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm + Sweden + + EMail: johani@autonomica.se + + + Pekka Savola + CSC/FUNET + + Espoo + Finland + + EMail: psavola@funet.fi + +Appendix A. Site-local Addressing Considerations for DNS + + As site-local addressing is being deprecated, and it is not yet clear + whether an addressing-based replacement (and which kind) is devised, + the considerations for site-local addressing are discussed briefly + here. + + The interactions with DNS come in two flavors: forward and reverse + DNS. + + To actually use site-local addresses within a site, this implies the + deployment of a "split-faced" or a fragmented DNS name space, for the + + + +Durand, et al. Expires July 1, 2004 [Page 19] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 2004 + + + zones internal to the site, and the outsiders' view to it. The + procedures to achieve this are not elaborated here. The implication + is that site-local addresses must not be published in the public DNS. + + To faciliate reverse DNS (if desired) with site-local addresses, the + stub resolvers must look for DNS information from the local DNS + servers, not e.g. starting from the root servers, so that the + site-local information may be provided locally. Note that the + experience private addresses in IPv4 has shown that the root servers + get loaded for requests for private address lookups in any. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires July 1, 2004 [Page 20] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 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 + + + +Durand, et al. Expires July 1, 2004 [Page 21] + +Internet-Draft Considerations and Issues with IPv6 DNS Jan 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires July 1, 2004 [Page 22] + + diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt new file mode 100644 index 0000000000..b2e2341be9 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt @@ -0,0 +1,300 @@ +Internet Engineering Task Force A.Durand +INTERNET-DRAFT SUN Microsystems,inc. +November, 24, 2003 J. Ihren +Expires May 25, 2004 Autonomica + + + DNS IPv6 transport operational guidelines + + + + +Status of this Memo + + This memo provides information to the Internet community. It does not + specify an Internet standard of any kind. This memo is in full + conformance with all provisions of Section 10 of RFC2026 + + 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/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + +Abstract + + This memo provides guidelines and Best Current Practice to operate + DNS in a world where queries and responses are carried in a mixed + environment of IPv4 and IPv6 networks. + + +Acknowledgment + + This document is the result of many conversations that happened in + the DNS community at IETF and elsewhere since 2001. During that + period of time, a number of Internet drafts have been published to + clarify various aspects of the issues at stake. This document focuses + on the conclusion of those discussions. + + The authors would like to acknowledge the role of Pekka Savola in his + thorough review of the document. + + +1. Terminology + + The phrase "IPv4 name server" indicates a name server available over + IPv4 transport. It does not imply anything about what DNS data is + served. Likewise, "IPv6 name server" indicates a name server + available over IPv6 transport. The phrase "dual-stack DNS server" + indicates a DNS server that is actually configured to run both + protocols, IPv4 and IPv6, and not merely a server running on a system + capable of running both but actually configured to run only one. + + 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 [2119]. + + +2. Introduction to the Problem of Name Space Fragmentation: + following the referral chain + + The caching resolver that tries to look up a name starts out at the + root, and follows referrals until it is referred to a nameserver that + is authoritative for the name. If somewhere down the chain of + referrals it is referred to a nameserver that is only accessible over + an unavailable type of transport, a traditional nameserver is unable + to finish the task. + + When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is + only a matter of time until this starts to happen. The complete DNS + hierarchy then starts to fragment into a graph where authoritative + nameservers for certain nodes are only accessible over a certain + transport. What is feared is that a node using only a particular + version of IP, querying information about another node using the same + version of IP can not do it because, somewhere in the chain of + servers accessed during the resolution process, one or more of them + will only be accessible with the other version of IP. + + With all DNS data only available over IPv4 transport everything is + simple. IPv4 resolvers can use the intended mechanism of following + referrals from the root and down while IPv6 resolvers have to work + through a "translator", i.e. they have to use a second name server on + a so-called "dual stack" host as a "forwarder" since they cannot + access the DNS data directly. + + With all DNS data only available over IPv6 transport everything would + be equally simple, with the exception of old legacy IPv4 name servers + having to switch to a forwarding configuration. + + However, the second situation will not arise in a foreseeable time. + Instead, it is expected that the transition will be from IPv4 only to + a mixture of IPv4 and IPv6, with DNS data of theoretically three + categories depending on whether it is available only over IPv4 + transport, only over IPv6 or both. + + Having DNS data available on both transports is the best situation. + The major question is how to ensure that it as quickly as possible + becomes the norm. However, while it is obvious that some DNS data + will only be available over v4 transport for a long time it is also + obvious that it is important to avoid fragmenting the name space + available to IPv4 only hosts. I.e. during transition it is not + acceptable to break the name space that we presently have available + for IPv4-only hosts. + + +3. Policy Based Avoidance of Name Space Fragmentation + + Today there are only a few DNS "zones" on the public Internet that + are available over IPv6 transport, and most of them can be regarded + as "experimental". However, as soon as the root and top level domains + are available over IPv6 transport, it is reasonable to expect that it + will become more common to have zones served by IPv6 servers. + + Having those zones served only by IPv6-only name server would not be + a good development, since this will fragment the previously + unfragmented IPv4 name space and there are strong reasons to find a + mechanism to avoid it. + + The RECOMMENDED approach to maintain name space continuity is to use + administrative policies, as described in the next section. + + +4. DNS IPv6 Transport RECOMMENDED Guidelines + + In order to preserve name space continuity, the following administrative + policies are RECOMMENDED: + - every recursive DNS server SHOULD be either IPv4-only or dual + stack, + - every single DNS zone SHOULD be served by at least one IPv4 + reachable DNS server. + + This rules out IPv6-only DNS servers performing full recursion and + DNS zones served only by IPv6-only DNS servers. However, one could + very well design a configuration where a chain of IPv6 only DNS + servers forward queries to a set of dual stack DNS servers actually + performing those recursive queries. This approach could be revisited + if/when translation techniques between IPv4 and IPv6 were to be + widely deployed. + + In order to help enforcing the second point, the optional operational + zone validation processes SHOULD ensure that there is at least one + IPv4 address record available for the name servers of any child + delegations within the zone. + + +5. Security Considerations + + Being a critical piece of the Internet infrastructure, the DNS is a + potential value target and thus should be protected. Great care + should be taken not to weaken the security of DNS while introducing + IPv6 operation. + + Keeping the DNS name space from fragmenting is a critical thing for + the availability and the operation of the Internet; this memo + addresses this issue by clear and simple operational guidelines. + + The RECOMMENDED guidelines are compatible with the operation of + DNSSEC and do not introduce any new security issues. + + +6. Author Addresses + + Alain Durand + SUN Microsystems, Inc + 17 Network circle UMPK17-202 + Menlo Park, CA, 94025 + USA + Mail: Alain.Durand@sun.com + + Johan Ihren + Autonomica + Bellmansgatan 30 + SE-118 47 Stockholm, Sweden + Mail: johani@autonomica.se + + +7. Normative References + + [2119] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + +8. 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-00.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-00.txt new file mode 100644 index 0000000000..77e68d919e --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-00.txt @@ -0,0 +1,447 @@ + +DNSOP G. Guette +Internet-Draft IRISA/INRIA Rennes +Expires: August 8, 2004 O. Courtay + ENST-Bretagne + February 8, 2004 + + + Requirements for Automated Key Rollover in DNSsec + draft-ietf-dnsop-key-rollover-requirements-00 + +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 8, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document describes problems that appear during an automated + rollover and gives the requirements for the design of communication + between parent zone and child zone in an automated rollover process. + This document is essentially about key rollover, the rollover of + one other Resource Record present at delegation point (NS RR) is + also discussed. + + + + + + + +Guette & Courtay Expires August 8, 2004 [Page 1] + +Internet-Draft Automated Rollover Requirements February 2004 + + +1. Introduction + + The DNS security extensions (DNSsec) [1] uses public-key cryptography + and digital signatures. It stores the public keys in KEY Resource + Records (RRs). Because old keys and frequently used keys are + vulnerable, they must be changed periodically. In DNSsec this is the + case for Zone Signing Keys (ZSKs) and Key Signing Keys (KSKs) [2, 4]. + Automation of key rollover process is necessary for large zones + because inside a large zone, there are too many changes to handle for + a single administrator. + + Let us consider for example a zone with one million child zones among + which only 10% of secured child zones. If the child zones change their + keys once a year on average, that implies 300 changes per day for the + parent zone. All these changes are hard to manage manually. + + Automated rollover is optional and resulting from an agreement + between the administrator of the parent zone and the administrator of + the child zone. Of course, key rollover can also be done manually by + administrators. + + This document describes the requirements for the design of messages + of automated key rollover process. + + +2. The Key Rollover Process + + Key rollover consists in replacing the DNSsec keys used to sign + resource records in a given DNS zone file. There are two types of + rollover, ZSK rollover and KSK rollover. + In ZSK rollover, all changes are local to the zone that changes its + key: there is no need to contact other zones (e.g. parent zone) to + propagate the performed changes because this type of key have no + associated DS records in the parent zone. + In KSK rollover, new DS RR(s) MUST be created and stored in the + parent zone. In consequence, the child zone MUST contact its parent + zone and notify it about the KSK change(s). + + Manual key rollover exists and works [3]. The key rollover is built + from two parts of different nature: + - An algorithm that generates new keys. It could be local to the + zone + - The interaction between parent and child zone + + In this document we focus on the interaction between parent and + child zone servers. + One example of manual key rollover is: + Child zone creates a new KSK, waiting for the creation of the DS + + + +Guette & Courtay Expires August 8, 2004 [Page 2] + +Internet-Draft Automated Rollover Requirements February 2004 + + + record in its parent zone and then child zone deletes old key. + + In manual rollover, communications are managed by the zone + administrators and the security of these communications is out of + scope of DNSsec. + + Automated key rollover MUST use a secure communication between parent + and child zone. In this document we concentrate our efforts on + defining interactions between entities present in key rollover + process that are not explicitly defined in manual key rollover + method. + + +3. Basic Requirements + + The main constraint to respect during a key rollover is that the + chain of trust MUST be preserved. Even if a resolver retrieve some RRs + from recursive name server. Every RR MUST be verifiable at any time, + every message exchanged during rollover MUST be authenticated and + data integrity MUST be guaranteed. + + Two entities are present during a KSK rollover: the child zone and + its parent zone. These zones are generally managed by different + administrators. These administrators MUST agree on some parameters + like availability of automated rollover, the maximum delay between + notification of changes in the child zone and the resigning of the + parent zone. The child zone needs to know this delay to schedule its + changes. + + During an automated rollover process, data are transmitted between + the primary name server of the parent and the the primary name server + of the child zone. + The reason is that the IP address of the primary name server is easy + to obtain. + Other solutions based on machine dedicated to the rollover are not + suitable solutions because of the difficulty to obtain the IP + addresses of the dedicated machine in an automated manner. + + +4. Messages authentication and information exchanged + + Every exchanged message MUST be authenticated and the authentication + tool MUST be a DNSsec tool such as TSIG [5], SIG(0) [6] or DNSsec + request with verifiable SIG records. + + Once the changes related to a KSK are made in a child zone, this zone + + + + +Guette & Courtay Expires August 8, 2004 [Page 3] + +Internet-Draft Automated Rollover Requirements February 2004 + + + MUST notify its parent zone in order to create the new DS RR and + store this DS RR in parent zone file. + + The parent zone MUST receive all the child Keys that needs the + creation of an associated DS RRs in the parent zone. + + Some errors could occur during transmission between child zone and + parent zone. Key rollover solution MUST be fault tolerant, i.e. at + any time the rollover MUST be in a consistent state and all RRs MUST + be verifiable, even if an error occurs. That is to say that it MUST + remains a valid chain of trust. + + +5. Emergency Rollover + + A key of a zone might be compromised and this key MUST be changed as + soon as possible. Fast changes could break the chain of trust. The + part of DNS tree having this zone as apex can become unverifiable, + but the break of the chain of trust is necessary if we want to no one + can use the compromised key to spoof DNS data. + + Parent zone behavior after an emergency rollover in one of its child + zone is an open discussion. + Should we define: + + - an EMERGENCY flag. When a child zone does an emergency KSK change, + it uses the EMERGENCY flag to notify its parents that the chain of + trust is broken and will stay broken until right DS creation and a + parent zone resigning. + + - a maximum time delay after next parent zone resigning, we ensure + that after this delay the parent zone is resigned and the right DS + is created. + + - that no pre-defined behavior for the parent zone is needed + + +6. Other Resource Record concerned by automatic rollover + + NS records are also present at delegation point, so when the child + zone changes some NS records, the corresponding records at + delegation point in parent zone MUST be updated. NS records are + concerned by rollover and this rollover could be automated too. In + this case, when the child zone notifies its parent zone that some NS + records have been changed, the parent zone MUST verify that these NS + records are present in child zone before doing any changes in its own + zone file. This allow to avoid inconsistency between NS records at + delegation point and NS records present in the child zone. + + + + +Guette & Courtay Expires August 8, 2004 [Page 4] + +Internet-Draft Automated Rollover Requirements February 2004 + + +7. Security consideration + + This document describes requirements to design an automated key + rollover in DNSsec based on DNSsec security. In the same way the, as + plain DNSsec, the automatic key rollover contains no mechanism + protecting against denial of service (DoS) resistant. The security + level obtain after an automatic key rollover, is the security level + provided by DNSsec. + + +8. Acknowledgments + The authors want to acknowledge Mohsen Souissi, Bernard Cousin, + Bertrand Leonard and members of IDsA project for their contribution + to this document. + + +Normative references + + [1] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [2] Gudmundsson, O., "Delegation Signer Resource Record", + draft-ietf-dnsext-delegation-signer-15 (work in progress), + June 2003. + + [3] Kolkman, O. and Gieben, R., "DNSSEC key operations", + draft-ietf-dnsext-operational-practices (work in progress), + June 2003. + + [4] Kolkman, O. and Schlyter, J., "KEY RR Secure Entry Point Flag" + draft-ietf-dnsext-keyrr-key-signing-flag-10 (work in progress), + September 2003. + + [5] Vixie, P., Gudmundsson, O., Eastlake, D., and Wellington, B., + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + + [6] Eastlake, D., "DNS Request and Transaction Signatures (SIG(0)s)", + RFC 2931, September 2000. + + [7] Eastlake, D.,"DNS Security Operational Considerations", RFC + 2541, March 1999. + + + + + + + + + +Guette & Courtay Expires August 8, 2004 [Page 5] + +Internet-Draft Automated Rollover Requirements October 2003 + + +Author's Addresses + + Gilles Guette + IRISA/INRIA Rennes + Campus Universitaire de Beaulieu + 35042 Rennes France + Phone : (33) 02 99 84 71 32 + Fax : (33) 02 99 84 25 29 + E-mail : gguette@irisa.fr + + Olivier Courtay + ENST-Bretagne + 2, rue de la ch‚taigneraie + 35512 Cesson C‰vign‰ CEDEX France + Phone : (33) 02 99 84 71 31 + Fax : (33) 02 99 84 25 29 + olivier.courtay@enst-bretagne.fr + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Guette & Courtay Expires August 8, 2004 [Page 6] + +Internet-Draft Automated Rollover Requirements February 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 (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 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 + + + +Guette & Courtay Expires August 8, 2004 [Page 7] + +Internet-Draft Automated Rollover Requirements February 2004 + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Guette & Courtay Expires August 8, 2004 [Page 8] + diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt new file mode 100644 index 0000000000..2d5c87eb3c --- /dev/null +++ b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt @@ -0,0 +1,1200 @@ + + + + + + +IPv6 Working Group John Loughney (ed) +Internet-Draft Nokia + January 14, 2004 + +Expires: July 14, 2004 + + + + IPv6 Node Requirements + draft-ietf-ipv6-node-requirements-08.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. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines requirements for IPv6 nodes. It is expected + that IPv6 will be deployed in a wide range of devices and situations. + Specifying the requirements for IPv6 nodes allows IPv6 to function + well and interoperate in a large number of situations and + deployments. + + + + + +Loughney (editor) February 16, 2004 [Page 1] + + + + + +Internet-Draft + + +Table of Contents + + 1. Introduction + 1.1 Requirement Language + 1.2 Scope of this Document + 1.3 Description of IPv6 Nodes + 2. Abbreviations Used in This Document + 3. Sub-IP Layer + 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + 3.2 IP version 6 over PPP - RFC2472 + 3.3 IPv6 over ATM Networks - RFC2492 + 4. IP Layer + 4.1 Internet Protocol Version 6 - RFC2460 + 4.2 Neighbor Discovery for IPv6 - RFC2461 + 4.3 Path MTU Discovery & Packet Size + 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + 4.5 Addressing + 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + 5. Transport and DNS + 5.1 Transport Layer + 5.2 DNS + 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) + 6. IPv4 Support and Transition + 6.1 Transition Mechanisms + 7. Mobility + 8. Security + 8.1 Basic Architecture + 8.2 Security Protocols + 8.3 Transforms and Algorithms + 8.4 Key Management Methods + 9. Router Functionality + 9.1 General + 10. Network Management + 10.1 MIBs + 11. Security Considerations + 12. References + 12.1 Normative + 12.2 Non-Normative + 13. Authors and Acknowledgements + 14. Editor's Address + Notices + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 2] + + + + + +Internet-Draft + + +1. Introduction + + The goal of this document is to define the common functionality + required from both IPv6 hosts and routers. Many IPv6 nodes will + implement optional or additional features, but all IPv6 nodes can be + expected to implement the mandatory requirements listed in this + document. + + This document tries to avoid discussion of protocol details, and + references RFCs for this purpose. In case of any conflicting text, + this document takes less precedence than the normative RFCs, unless + additional clarifying text is included in this document. + + Although the document points to different specifications, it should + be noted that in most cases, the granularity of requirements are + smaller than a single specification, as many specifications define + multiple, independent pieces, some of which may not be mandatory. + + As it is not always possible for an implementer to know the exact + usage of IPv6 in a node, an overriding requirement for IPv6 nodes is + that they should adhere to Jon Postel's Robustness Principle: + + Be conservative in what you do, be liberal in what you accept from + others [RFC-793]. + +1.1 Requirement Language + + 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 [RFC-2119]. + +1.2 Scope of this Document + + IPv6 covers many specifications. It is intended that IPv6 will be + deployed in many different situations and environments. Therefore, + it is important to develop the requirements for IPv6 nodes, in order + to ensure interoperability. + + This document assumes that all IPv6 nodes meet the minimum + requirements specified here. + +1.3 Description of IPv6 Nodes + + From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we + have the following definitions: + + Description of an IPv6 Node + + + + +Loughney (editor) February 16, 2004 [Page 3] + + + + + +Internet-Draft + + + - a device that implements IPv6 + + Description of an IPv6 router + + - a node that forwards IPv6 packets not explicitly addressed to + itself. + + Description of an IPv6 Host + + - any node that is not a router. + +2. Abbreviations Used in This Document + + ATM Asynchronous Transfer Mode + + AH Authentication Header + + DAD Duplicate Address Detection + + ESP Encapsulating Security Payload + + ICMP Internet Control Message Protocol + + IKE Internet Key Exchange + + MIB Management Information Base + + MLD Multicast Listener Discovery + + MTU Maximum Transfer Unit + + NA Neighbor Advertisement + + NBMA Non-Broadcast Multiple Access + + ND Neighbor Discovery + + NS Neighbor Solicitation + + NUD Neighbor Unreachability Detection + + PPP Point-to-Point Protocol + + PVC Permanent Virtual Circuit + + SVC Switched Virtual Circuit + +3. Sub-IP Layer + + + +Loughney (editor) February 16, 2004 [Page 4] + + + + + +Internet-Draft + + + An IPv6 node must include support for one or more IPv6 link-layer + specifications. Which link-layer specifications are included will + depend upon what link-layers are supported by the hardware available + on the system. It is possible for a conformant IPv6 node to support + IPv6 on some of its interfaces and not on others. + + As IPv6 is run over new layer 2 technologies, it is expected that new + specifications will be issued. This section highlights some major + layer 2 technologies and is not intended to be complete. + +3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 + + Nodes supporting IPv6 over Ethernet interfaces MUST implement + Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. + +3.2 IP version 6 over PPP - RFC2472 + + Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC- + 2472]. + +3.3 IPv6 over ATM Networks - RFC2492 + + Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM + Networks [RFC-2492]. Additionally, RFC 2492 states: + + A minimally conforming IPv6/ATM driver SHALL support the PVC mode + of operation. An IPv6/ATM driver that supports the full SVC mode + SHALL also support PVC mode of operation. + +4. IP Layer + +4.1 Internet Protocol Version 6 - RFC2460 + + The Internet Protocol Version 6 is specified in [RFC-2460]. This + specification MUST be supported. + + Unrecognized options in Hop-by-Hop Options or Destination Options + extensions MUST be processed as described in RFC 2460. + + The node MUST follow the packet transmission rules in RFC 2460. + + Nodes MUST always be able to send, receive and process fragment + headers. All conformant IPv6 implementations MUST be capable of + sending and receving IPv6 packets; forwarding functionality MAY be + supported + + RFC 2460 specifies extension headers and the processing for these + headers. + + + +Loughney (editor) February 16, 2004 [Page 5] + + + + + +Internet-Draft + + + A full implementation of IPv6 includes implementation of the + following extension headers: Hop-by-Hop Options, Routing (Type 0), + Fragment, Destination Options, Authentication and Encapsulating + Security Payload. [RFC-2460] + + An IPv6 node MUST be able to process these headers. It should be + noted that there is some discussion about the use of Routing Headers + and possible security threats [IPv6-RH] caused by them. + +4.2 Neighbor Discovery for IPv6 - RFC2461 + + Neighbor Discovery SHOULD be supported. RFC 2461 states: + + "Unless specified otherwise (in a document that covers operating + IP over a particular link type) this document applies to all link + types. However, because ND uses link-layer multicast for some of + its services, it is possible that on some link types (e.g., NBMA + links) alternative protocols or mechanisms to implement those + services will be specified (in the appropriate document covering + the operation of IP over a particular link type). The services + described in this document that are not directly dependent on + multicast, such as Redirects, Next-hop determination, Neighbor + Unreachability Detection, etc., are expected to be provided as + specified in this document. The details of how one uses ND on + NBMA links is an area for further study." + + Some detailed analysis of Neighbor Discovery follows: + + Router Discovery is how hosts locate routers that reside on an + attached link. Router Discovery MUST be supported for + implementations. + + Prefix Discovery is how hosts discover the set of address prefixes + that define which destinations are on-link for an attached link. + Prefix discovery MUST be supported for implementations. Neighbor + Unreachability Detection (NUD) MUST be supported for all paths + between hosts and neighboring nodes. It is not required for paths + between routers. However, when a node receives a unicast Neighbor + Solicitation (NS) message (that may be a NUD's NS), the node MUST + respond to it (i.e. send a unicast Neighbor Advertisement). + + Duplicate Address Detection MUST be supported on all links supporting + link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take + place on all unicast addresses). + + A host implementation MUST support sending Router Solicitations. + + Receiving and processing Router Advertisements MUST be supported for + + + +Loughney (editor) February 16, 2004 [Page 6] + + + + + +Internet-Draft + + + host implementations. The ability to understand specific Router + Advertisement options is dependent on supporting the specification + where the RA is specified. + + Sending and Receiving Neighbor Solicitation (NS) and Neighbor + Advertisement (NA) MUST be supported. NS and NA messages are required + for Duplicate Address Detection (DAD). + + Redirect functionality SHOULD be supported. If the node is a router, + Redirect functionality MUST be supported. + +4.3 Path MTU Discovery & Packet Size + +4.3.1 Path MTU Discovery - RFC1981 + + Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal + implementations MAY choose to not support it and avoid large packets. + The rules in RFC 2460 MUST be followed for packet fragmentation and + reassembly. + +4.3.2 IPv6 Jumbograms - RFC2675 + + IPv6 Jumbograms [RFC-2675] MAY be supported. + +4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463 + + ICMPv6 [RFC-2463] MUST be supported. + +4.5 Addressing + +4.5.1 IP Version 6 Addressing Architecture - RFC3513 + + The IPv6 Addressing Architecture [RFC-3513] MUST be supported. + +4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462 + + IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. + This specification MUST be supported for nodes that are hosts. + + Nodes that are routers MUST be able to generate link local addresses + as described in RFC 2462 [RFC-2462]. + + From 2462: + + The autoconfiguration process specified in this document applies + only to hosts and not routers. Since host autoconfiguration uses + information advertised by routers, routers will need to be + configured by some other means. However, it is expected that + + + +Loughney (editor) February 16, 2004 [Page 7] + + + + + +Internet-Draft + + + routers will generate link-local addresses using the mechanism + described in this document. In addition, routers are expected to + successfully pass the Duplicate Address Detection procedure + described in this document on all addresses prior to assigning + them to an interface. + + Duplicate Address Detection (DAD) MUST be supported. + +4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041 + + Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] + SHOULD be supported. It is recommended that this behavior be + configurable on a connection basis within each application when + available. It is noted that a number of applications do not work + with addresses generated with this method, while other applications + work quite well with them. + +4.5.4 Default Address Selection for IPv6 - RFC3484 + + The rules specified in the Default Address Selection for IPv6 [RFC- + 3484] document MUST be implemented. It is expected that IPv6 nodes + will need to deal with multiple addresses. + +4.5.5 Stateful Address Autoconfiguration + + Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC- + 3315] is the standard stateful address configuration protocol; see + section 5.3 for DHCPv6 support. + + Nodes which do not support Stateful Address Autoconfiguration may be + unable to obtain any IPv6 addresses aside from link-local addresses + when it receives a router advertisement with the 'M' flag (Managed + address configuration) set and which contains no prefixes advertised + for Stateless Address Autoconfiguration (see section 4.5.2). + Additionally, such nodes will be unable to obtain other configuration + information such as the addresses of DNS servers when it is connected + to a link over which the node receives a router advertisement in + which the 'O' flag ("Other stateful configuration") is set. + +4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710 + + Nodes that need to join multicast groups SHOULD implement MLDv2 + [MLDv2]. However, if the node has applications, which only need + support for Any- Source Multicast [RFC3569], the node MAY implement + MLDv1 [MLDv1] instead. If the node has applications, which need + support for Source- Specific Multicast [RFC3569, SSMARCH], the node + MUST support MLDv2 [MLDv2]. + + + + +Loughney (editor) February 16, 2004 [Page 8] + + + + + +Internet-Draft + + + When MLD is used, the rules in "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be + followed. + +5. Transport Layer and DNS + +5.1 Transport Layer + +5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147 + + This specification MUST be supported if jumbograms are implemented + [RFC- 2675]. + +5.2 DNS + + DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363] + and [RFC-3596] MAY be supported. Not all nodes will need to resolve + names. All nodes that need to resolve names SHOULD implement stub- + resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with + support for: + + - AAAA type Resource Records [RFC-3596]; + - reverse addressing in ip6.arpa using PTR records [RFC-3152]; + - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512 + octets. + + Those nodes are RECOMMENDED to support DNS security extentions + [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT]. + + Those nodes are NOT RECOMMENDED to support the experimental A6 and + DNAME Resource Records [RFC-3363]. + +5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732 + + RFC 2732 MUST be supported if applications on the node use URL's. + +5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315 + +5.3.1 Managed Address Configuration + + Those IPv6 Nodes that use DHCP for address assignment initiate DHCP + to obtain IPv6 addresses and other configuration information upon + receipt of a Router Advertisement with the 'M' flag set, as described + in section 5.5.3 of RFC 2462. In addition, in the absence of a + router, those IPv6 Nodes that use DHCP for address assignment MUST + initiate DHCP to obtain IPv6 addresses and other configuration + information, as described in section 5.5.2 of RFC 2462. Those IPv6 + nodes that do not use DHCP for address assignment can ignore the 'M' + + + +Loughney (editor) February 16, 2004 [Page 9] + + + + + +Internet-Draft + + + flag in Router Advertisements. + +5.3.2 Other Configuration Information + + Those IPv6 Nodes that use DHCP to obtain other configuration + information initiate DHCP for other configuration information upon + receipt of a Router Advertisement with the 'O' flag set, as described + in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP + for other configuration information can ignore the 'O' flag in Router + Advertisements. + + An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to + obtain other configuration information. + +6. IPv4 Support and Transition + + IPv6 nodes MAY support IPv4. + +6.1 Transition Mechanisms + +6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893 + + If an IPv6 node implements dual stack and tunneling, then RFC2893 + MUST be supported. + + RFC 2893 is currently being updated. + +7. Mobile IP + + The Mobile IPv6 [MIPv6] specification defines requirements for the + following types of nodes: + + - mobile nodes + - correspondent nodes with support for route optimization + - home agents + - all IPv6 routers + + Hosts MAY support mobile node functionality described in Section 8.5 + of [MIPv6], including support of generic packet tunneling [RFC-2473] + and secure home agent communications [MIPv6-HASEC]. + + Hosts SHOULD support route optimization requirements for + correspondent nodes described in Section 8.2 of [MIPv6]. + + Routers SHOULD support the generic mobility-related requirements for + all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY + support the home agent functionality described in Section 8.4 of + [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC]. + + + +Loughney (editor) February 16, 2004 [Page 10] + + + + + +Internet-Draft + + +8. Security + + This section describes the specification of IPsec for the IPv6 node. + +8.1 Basic Architecture + + Security Architecture for the Internet Protocol [RFC-2401] MUST be + supported. RFC-2401 is being updated by the IPsec Working Group. + +8.2 Security Protocols + + ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported. + RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group. + + +8.3 Transforms and Algorithms + + Current IPsec RFCs specify the support of certain transforms and + algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96. + The requirements for these are discussed first, and then additional + algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed. + + NULL encryption algorithm [RFC-2410] MUST be supported for providing + integrity service and also for debugging use. + + The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD + NOT be supported. Security issues related to the use of DES are + discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as + required by the existing IPsec RFCs, but as it is currently viewed as + an inherently weak algorithm, and no longer fulfills its intended + role. + + The NULL authentication algorithm [RFC-2406] MUST be supported within + ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC- + 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP, + described in [RFC-2403] MUST be supported. An implementer MUST refer + to Keyed- Hashing for Message Authentication [RFC-2104]. + + 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC + and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES- + CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected + to be a widely available, secure algorithm that is required for + interoperability. It is not required by the current IPsec RFCs, but + is expected to become required in the future. + + In addition to the above requirements, "Cryptographic Algorithm + Implementation Requirements For ESP And AH" [CRYPTREQ] contains the + current set of mandatory to implement algorithms for ESP and AH as + + + +Loughney (editor) February 16, 2004 [Page 11] + + + + + +Internet-Draft + + + well as specifying algorithms that should be implemented because they + may be promoted to mandatory at some future time. It is RECOMMENDED + that IPv6 nodes conform to the requirements in this document. + +8.4 Key Management Methods + + Manual keying MUST be supported. + + IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast + traffic. Where key refresh, anti-replay features of AH and ESP, or + on- demand creation of Security Associations (SAs) is required, + automated keying MUST be supported. Note that the IPsec WG is working + on the successor to IKE [IKE2]. Key management methods for multicast + traffic are also being worked on by the MSEC WG. + + "Cryptographic Algorithms for use in the Internet Key Exchange + Version 2" [IKEv2ALGO] defines the current set of mandatory to + implement algorithms for use of IKEv2 as well as specifying + algorithms that should be implemented because they made be promoted + to mandatory at some future time. It is RECOMMENDED that IPv6 nodes + implementing IKEv2 conform to the requirements in this + document. + +9. Router-Specific Functionality + + This section defines general host considerations for IPv6 nodes that + act as routers. Currently, this section does not discuss routing- + specific requirements. + +9.1 General + +9.1.1 IPv6 Router Alert Option - RFC2711 + + + The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- + Hop Header that is used in conjunction with some protocols (e.g., + RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will + need to be implemented whenever protocols that mandate its usage are + implemented. See Section 4.6. + +9.1.2 Neighbor Discovery for IPv6 - RFC2461 + + Sending Router Advertisements and processing Router Solicitation MUST + be supported. + +10. Network Management + + Network Management MAY be supported by IPv6 nodes. However, for IPv6 + + + +Loughney (editor) February 16, 2004 [Page 12] + + + + + +Internet-Draft + + + nodes that are embedded devices, network management may be the only + possibility to control these nodes. + +10.1 Management Information Base Modules (MIBs) + + The following two MIBs SHOULD be supported by nodes that support an + SNMP agent. + +10.1.1 IP Forwarding Table MIB + + IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes + that support an SNMP agent. + +10.1.2 Management Information Base for the Internet Protocol (IP) + + IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an + SNMP agent. + +11. Security Considerations + + This draft does not affect the security of the Internet, but + implementations of IPv6 are expected to support a minimum set of + security features to ensure security on the Internet. "IP Security + Document Roadmap" [RFC-2411] is important for everyone to read. + + The security considerations in RFC2460 describe the following: + + The security features of IPv6 are described in the Security + Architecture for the Internet Protocol [RFC-2401]. + +12. References + +12.1 Normative + + [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa- + tion Requirements For ESP And AH", draft-ietf-ipsec- + esp-ah-algorithms-01.txt, January 2004. + + [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the + Internet Key Exchange Version 2", draft-ietf-ipsec- + ikev2-algorithms-04.txt, Work in Progress. + + [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6 + Service", draft- ietf-dhc-dhcpv6-stateless-00.txt, + Work in Progress. + + [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support + in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 13] + + + + + +Internet-Draft + + + progress. + + [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec + to Protect Mobile IPv6 Signaling between Mobile Nodes + and Home Agents", draft-ietf- mobileip-mipv6-ha- + ipsec-06.txt, Work in Progress. + + [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version + 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in + Progress. + + [RFC-1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU + Discovery for IP version 6", RFC 1981, August 1996. + + [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table + MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in + Progress. + + [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the + Internet Protocol (IP)", draft-ietf-ipv6-rfc2011- + update-07.txt, Work in progress. + + [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC: + Keyed-Hashing for Message Authentication", RFC 2104, + February 1997. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for + the Internet Protocol", RFC 2401, November 1998. + + [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication + Header", RFC 2402, November 1998. + + [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within + ESP and AH", RFC 2403, November 1998. + + [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1 + within ESP and AH", RFC 2404, November 1998. + + [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security + + + +Loughney (editor) February 16, 2004 [Page 14] + + + + + +Internet-Draft + + + Protocol (ESP)", RFC 2406, November 1998. + + [RFC-2407] Piper, D., "The Internet IP Security Domain of + Interpretation for ISAKMP", RFC 2407, November 1998. + + [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner, + J., "Internet Security Association and Key Management + Protocol (ISAKMP)", RFC 2408, November 1998. + + [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key + Exchange (IKE)", RFC 2409, November 1998. + + [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm + and Its Use With IPsec", RFC 2410, November 1998. + + [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher + Algorithms", RFC 2451, November 1998. + + [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver- + sion 6 (IPv6) Specification", RFC 2460, December 1998. + + [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor + Discovery for IP Version 6 (IPv6)", RFC 2461, December + 1998. + + [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address + Autoconfiguration", RFC 2462. + + [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro- + tocol Version 6 (IPv6)", RFC 2463, December 1998. + + [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC + 2472, December 1998. + + [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling + in IPv6 Specification", RFC 2473, December 1998. Xxx + add + + [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert + Option", RFC 2711, October 1999. + + + + +Loughney (editor) February 16, 2004 [Page 15] + + + + + +Internet-Draft + + + [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC + 3041, January 2001. + + [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August + 2001. + + [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver- + sion 6 (IPv6) Addresses in the Domain Name System + (DNS)", RFC 3363, August 2002. + + [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC + 3484, February 2003. + + [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing + Architecture", RFC 3513, April 2003. + + [RFC-3590] Haberman, B., "Source Address Selection for the Multi- + cast Listener Discovery (MLD) Protocol", RFC 3590, + September 2003. + + [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP + version 6", RFC 3596, October 2003. + + [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use + with IPsec", RFC 3602, September 2003. + +12.2 Non-Normative + + [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast", + draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in + Progress. + + [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of + DES-like cryptosystems", Journal of Cryptology Vol 4, Jan + 1991. + + [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000. + + [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without + Strong Integrity", Proceedings of the 32nd IETF, Danvers, + MA, April 1995. + + [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser- + vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in + + + +Loughney (editor) February 16, 2004 [Page 16] + + + + + +Internet-Draft + + + Progress. + + [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "DNS Security Introduction and Requirements" draft- + ietf-dnsext-dnssec-intro- 06.txt, Work in Progress. + + [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Resource Records for the DNS Security Extensions", + draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro- + gress. + + [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, + S., "Protocol Modifications for the DNS Security Exten- + sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work + in Progress. + + [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto- + col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress. + + [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home + Address Options", draft-savola-ipv6-rh-ha-security- + 03.txt, Work in Progress, March 2002. + + [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu- + rity Threats and Counter-Measures; In Proceedings "Sympo- + sium on Network and Distributed System Security", Febru- + ary 1995, pp.2-16. + + [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793, + August 1980. + + [RFC-1034] Mockapetris, P., "Domain names - concepts and facili- + ties", RFC 1034, November 1987. + + [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, + May 1997. + + [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and + S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC + 2205, September 1997. + + [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet + Networks", RFC 2462, December 1998. + + [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over + ATM Networks", RFC 2492, January 1999. + + [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6 + + + +Loughney (editor) February 16, 2004 [Page 17] + + + + + +Internet-Draft + + + Jumbograms", RFC 2675, August 1999. + + [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal + IPv6 Addresses in URL's", RFC 2732, December 1999. + + [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder, + "Textual Conventions for Internet Network Addresses", RFC + 2851, June 2000. + + [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for + IPv6 Hosts and Routers", RFC 2893, August 2000. + + [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", + draft-ietf- ssm-arch-03.txt, Work in Progress. + +13. Authors and Acknowledgements + + This document was written by the IPv6 Node Requirements design team: + + Jari Arkko + [jari.arkko@ericsson.com] + + Marc Blanchet + [marc.blanchet@viagenie.qc.ca] + + Samita Chakrabarti + [samita.chakrabarti@eng.sun.com] + + Alain Durand + [alain.durand@sun.com] + + Gerard Gastaud + [gerard.gastaud@alcatel.fr] + + Jun-ichiro itojun Hagino + [itojun@iijlab.net] + + Atsushi Inoue + [inoue@isl.rdc.toshiba.co.jp] + + Masahiro Ishiyama + [masahiro@isl.rdc.toshiba.co.jp] + + John Loughney + [john.loughney@nokia.com] + + + +Loughney (editor) February 16, 2004 [Page 18] + + + + + +Internet-Draft + + + Rajiv Raghunarayan + [raraghun@cisco.com] + + Shoichi Sakane + [shouichi.sakane@jp.yokogawa.com] + + Dave Thaler + [dthaler@windows.microsoft.com] + + Juha Wiljakka + [juha.wiljakka@Nokia.com] + + The authors would like to thank Ran Atkinson, Jim Bound, Brian Car- + penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten, + Juha Ollila and Pekka Savola for their comments. + +14. Editor's Contact Information + + Comments or questions regarding this document should be sent to the + IPv6 Working Group mailing list (ipv6@ietf.org) or to: + + John Loughney + Nokia Research Center + Itamerenkatu 11-13 + 00180 Helsinki + Finland + + Phone: +358 50 483 6242 + Email: John.Loughney@Nokia.com + +Notices + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to per- + tain 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 + + + +Loughney (editor) February 16, 2004 [Page 19] + + + + + +Internet-Draft + + + rights, which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney (editor) February 16, 2004 [Page 20] + + diff --git a/doc/draft/update b/doc/draft/update new file mode 100644 index 0000000000..766f15b08e --- /dev/null +++ b/doc/draft/update @@ -0,0 +1,42 @@ +#!/bin/sh +for i +do + z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'` + if test -n "$z" + then + i="$z" + fi + if test -f "$i" + then + continue + fi + pat=`echo "$i" | sed 's/...txt/??.txt/'` + old=`echo $pat 2> /dev/null` + if test "X$old" != "X$pat" + then + newer=0 + for j in $old + do + if test $j ">" $i + then + newer=1 + fi + done + if test $newer = 1 + then + continue; + fi + fi + if fetch "http://www.ietf.org/internet-drafts/$i" + then + cvs add "$i" + if test "X$old" != "X$pat" + then + rm $old + cvs delete $old + else + old= + fi + cvs commit -m "new draft" $i $old + fi +done diff --git a/doc/rfc/rfc3658.txt b/doc/rfc/rfc3658.txt new file mode 100644 index 0000000000..88cfb5af24 --- /dev/null +++ b/doc/rfc/rfc3658.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group O. Gudmundsson +Request for Comments: 3658 December 2003 +Updates: 3090, 3008, 2535, 1035 +Category: Standards Track + + + Delegation Signer (DS) Resource Record (RR) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The delegation signer (DS) resource record (RR) is inserted at a zone + cut (i.e., a delegation point) to indicate that the delegated zone is + digitally signed and that the delegated zone recognizes the indicated + key as a valid zone key for the delegated zone. The DS RR is a + modification to the DNS Security Extensions definition, motivated by + operational considerations. The intent is to use this resource + record as an explicit statement about the delegation, rather than + relying on inference. + + This document defines the DS RR, gives examples of how it is used and + describes the implications on resolvers. This change is not + backwards compatible with RFC 2535. This document updates RFC 1035, + RFC 2535, RFC 3008 and RFC 3090. + + + + + + + + + + + + + + + + +Gudmundsson Standards Track [Page 1] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + +Table of Contents + + 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2. Reserved Words. . . . . . . . . . . . . . . . . . . . . 4 + 2. Specification of the Delegation key Signer. . . . . . . . . . 4 + 2.1. Delegation Signer Record Model. . . . . . . . . . . . . 4 + 2.2. Protocol Change . . . . . . . . . . . . . . . . . . . . 5 + 2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations + at Delegation Points . . . . . . . . . . . . . 6 + 2.2.1.1. Special processing for DS queries. . . 6 + 2.2.1.2. Special processing when child and an + ancestor share nameserver. . . . . . . 7 + 2.2.1.3. Modification on use of KEY RR in the + construction of Responses. . . . . . . 8 + 2.2.2. Signer's Name (replaces RFC3008 section 2.7). . 9 + 2.2.3. Changes to RFC 3090 . . . . . . . . . . . . . . 9 + 2.2.3.1. RFC 3090: Updates to section 1: + Introduction . . . . . . . . . . . . . 9 + 2.2.3.2. RFC 3090 section 2.1: Globally + Secured. . . . . . . . . . . . . . . . 10 + 2.2.3.3. RFC 3090 section 3: Experimental + Status . . . . . . . . . . . . . . . . 10 + 2.2.4. NULL KEY elimination. . . . . . . . . . . . . . 10 + 2.3. Comments on Protocol Changes. . . . . . . . . . . . . . 10 + 2.4. Wire Format of the DS record. . . . . . . . . . . . . . 11 + 2.4.1. Justifications for Fields . . . . . . . . . . . 12 + 2.5. Presentation Format of the DS Record. . . . . . . . . . 12 + 2.6. Transition Issues for Installed Base. . . . . . . . . . 12 + 2.6.1. Backwards compatibility with RFC 2535 and + RFC 1035. . . . . . . . . . . . . . . . . . . . 12 + 2.7. KEY and corresponding DS record example . . . . . . . . 13 + 3. Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 3.1. DS Example" . . . . . . . . . . . . . . . . . . . . . . 14 + 3.2. Resolver Cost Estimates for DS Records" . . . . . . . . 15 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 6. Intellectual Property Statement . . . . . . . . . . . . . . . 16 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.1. Normative References. . . . . . . . . . . . . . . . . . 17 + 8.2. Informational References. . . . . . . . . . . . . . . . 17 + 9. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 18 + 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19 + + + + + + + + +Gudmundsson Standards Track [Page 2] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + +1. Introduction + + Familiarity with the DNS system [RFC1035], DNS security extensions + [RFC2535], and DNSSEC terminology [RFC3090] is important. + + Experience shows that when the same data can reside in two + administratively different DNS zones, the data frequently gets out of + sync. The presence of an NS RRset in a zone anywhere other than at + the apex indicates a zone cut or delegation. The RDATA of the NS + RRset specifies the authoritative nameservers for the delegated or + "child" zone. Based on actual measurements, 10-30% of all + delegations on the Internet have differing NS RRsets at parent and + child. There are a number of reasons for this, including a lack of + communication between parent and child and bogus name servers being + listed to meet registry requirements. + + DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs + to have its KEY RRset signed by its parent to create a verifiable + chain of KEYs. There has been some debate on where the signed KEY + RRset should reside, whether at the child [RFC2535] or at the parent. + If the KEY RRset resides at the child, maintaining the signed KEY + RRset in the child requires frequent two-way communication between + the two parties. First, the child transmits the KEY RRset to the + parent and then the parent sends the signature(s) to the child. + Storing the KEY RRset at the parent was thought to simplify the + communication. + + DNSSEC [RFC2535] requires that the parent store a NULL KEY record for + an unsecure child zone to indicate that the child is unsecure. A + NULL KEY record is a waste: an entire signed RRset is used to + communicate effectively one bit of information - that the child is + unsecure. Chasing down NULL KEY RRsets complicates the resolution + process in many cases, because nameservers for both parent and child + need to be queried for the KEY RRset if the child nameserver does not + return it. Storing the KEY RRset only in the parent zone simplifies + this and would allow the elimination of the NULL KEY RRsets entirely. + For large delegation zones, the cost of NULL keys is a significant + barrier to deployment. + + Prior to the restrictions imposed by RFC 3445 [RFC3445], another + implication of the DNSSEC key model is that the KEY record could be + used to store public keys for other protocols in addition to DNSSEC + keys. There are a number of potential problems with this, including: + + 1. The KEY RRset can become quite large if many applications and + protocols store their keys at the zone apex. Possible protocols + are IPSEC, HTTP, SMTP, SSH and others that use public key + cryptography. + + + +Gudmundsson Standards Track [Page 3] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + + 2. The KEY RRset may require frequent updates. + + 3. The probability of compromised or lost keys, which trigger + emergency key roll-over procedures, increases. + + 4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone + keys. + + 5. The parent may not meet the child's expectations of turnaround + time for resigning the KEY RRset. + + Given these reasons, SIG@parent isn't any better than SIG/KEY@Child. + +1.2. Reserved Words + + The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED", + "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be + interpreted as described in BCP 14, RFC 2119 [RFC2119]. + +2. Specification of the Delegation key Signer + + This section defines the Delegation Signer (DS) RR type (type code + 43) and the changes to DNS to accommodate it. + +2.1. Delegation Signer Record Model + + This document presents a replacement for the DNSSEC KEY record chain + of trust [RFC2535] that uses a new RR that resides only at the + parent. This record identifies the key(s) that the child uses to + self-sign its own KEY RRset. + + Even though DS identifies two roles for KEYs, Key Signing Key (KSK) + and Zone Signing Key (ZSK), there is no requirement that zone uses + two different keys for these roles. It is expected that many small + zones will only use one key, while larger zones will be more likely + to use multiple keys. + + The chain of trust is now established by verifying the parent KEY + RRset, the DS RRset from the parent and the KEY RRset at the child. + This is cryptographically equivalent to using just KEY records. + + Communication between the parent and child is greatly reduced, since + the child only needs to notify the parent about changes in keys that + sign its apex KEY RRset. The parent is ignorant of all other keys in + the child's apex KEY RRset. Furthermore, the child maintains full + control over the apex KEY RRset and its content. The child can + maintain any policies regarding its KEY usage for DNSSEC with minimal + impact on the parent. Thus, if the child wants to have frequent key + + + +Gudmundsson Standards Track [Page 4] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + + roll-over for its DNS zone keys, the parent does not need to be aware + of it. The child can use one key to sign only its apex KEY RRset and + a different key to sign the other RRsets in the zone. + + This model fits well with a slow roll out of DNSSEC and the islands + of security model. In this model, someone who trusts "good.example." + can preconfigure a key from "good.example." as a trusted key, and + from then on trusts any data signed by that key or that has a chain + of trust to that key. If "example." starts advertising DS records, + "good.example." does not have to change operations by suspending + self-signing. DS records can be used in configuration files to + identify trusted keys instead of KEY records. Another significant + advantage is that the amount of information stored in large + delegation zones is reduced: rather than the NULL KEY record at every + unsecure delegation demanded by RFC 2535, only secure delegations + require additional information in the form of a signed DS RRset. + + The main disadvantage of this approach is that verifying a zone's KEY + RRset requires two signature verification operations instead of the + one in RFC 2535 chain of trust. There is no impact on the number of + signatures verified for other types of RRsets. + +2.2. Protocol Change + + All DNS servers and resolvers that support DS MUST support the OK bit + [RFC3225] and a larger message size [RFC3226]. In order for a + delegation to be considered secure the delegation MUST contain a DS + RRset. If a query contains the OK bit, a nameserver returning a + referral for the delegation MUST include the following RRsets in the + authority section in this order: + + If DS RRset is present: + parent's copy of child's NS RRset + DS and SIG(DS) + + If no DS RRset is present: + parent's copy of child's NS RRset + parent's zone NXT and SIG(NXT) + + This increases the size of referral messages, possibly causing some + or all glue to be omitted. If the DS or NXT RRsets with signatures + do not fit in the DNS message, the TC bit MUST be set. Additional + section processing is not changed. + + A DS RRset accompanying a NS RRset indicates that the child zone is + secure. If a NS RRset exists without a DS RRset, the child zone is + unsecure (from the parents point of view). DS RRsets MUST NOT appear + at non-delegation points or at a zone's apex. + + + +Gudmundsson Standards Track [Page 5] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + + Section 2.2.1 defines special considerations related to authoritative + nameservers responding to DS queries and replaces RFC 2535 sections + 2.3.4 and 3.4. Section 2.2.2 replaces RFC 3008 section 2.7, and + section 2.2.3 updates RFC 3090. + +2.2.1. RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation + Points + + DNS security views each zone as a unit of data completely under the + control of the zone owner with each entry (RRset) signed by a special + private key held by the zone manager. But the DNS protocol views the + leaf nodes in a zone that are also the apex nodes of a child zone + (i.e., delegation points) as "really" belonging to the child zone. + The corresponding domain names appear in two master files and might + have RRsets signed by both the parent and child zones' keys. A + retrieval could get a mixture of these RRsets and SIGs, especially + since one nameserver could be serving both the zone above and below a + delegation point [RFC2181]. + + Each DS RRset stored in the parent zone MUST be signed by at least + one of the parent zone's private keys. The parent zone MUST NOT + contain a KEY RRset at any delegation point. Delegations in the + parent MAY contain only the following RR types: NS, DS, NXT and SIG. + The NS RRset MUST NOT be signed. The NXT RRset is the exceptional + case: it will always appear differently and authoritatively in both + the parent and child zones, if both are secure. + + A secure zone MUST contain a self-signed KEY RRset at its apex. Upon + verifying the DS RRset from the parent, a resolver MAY trust any KEY + identified in the DS RRset as a valid signer of the child's apex KEY + RRset. Resolvers configured to trust one of the keys signing the KEY + RRset MAY now treat any data signed by the zone keys in the KEY RRset + as secure. In all other cases, resolvers MUST consider the zone + unsecure. + + An authoritative nameserver queried for type DS MUST return the DS + RRset in the answer section. + +2.2.1.1. Special processing for DS queries + + When a nameserver is authoritative for the parent zone at a + delegation point and receives a query for the DS record at that name, + it MUST answer based on data in the parent zone, return DS or + negative answer. This is true whether or not it is also + authoritative for the child zone. + + + + + + +Gudmundsson Standards Track [Page 6] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + + When the nameserver is authoritative for the child zone at a + delegation point but not the parent zone, there is no natural + response, since the child zone is not authoritative for the DS record + at the zone's apex. As these queries are only expected to originate + from recursive nameservers which are not DS-aware, the authoritative + nameserver MUST answer with: + + RCODE: NOERROR + AA bit: set + Answer Section: Empty + Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)] + + That is, it answers as if it is authoritative and the DS record does + not exist. DS-aware recursive nameservers will query the parent zone + at delegation points, so will not be affected by this. + + A nameserver authoritative for only the child zone, that is also a + caching server MAY (if the RD bit is set in the query) perform + recursion to find the DS record at the delegation point, or MAY + return the DS record from its cache. In this case, the AA bit MUST + NOT be set in the response. + +2.2.1.2. Special processing when child and an ancestor share + nameserver + + Special rules are needed to permit DS RR aware nameservers to + gracefully interact with older caches which otherwise might falsely + label a nameserver as lame because of the placement of the DS RR set. + + Such a situation might arise when a nameserver is authoritative for + both a zone and it's grandparent, but not the parent. This sounds + like an obscure example, but it is very real. The root zone is + currently served on 13 machines, and "root-servers.net." is served on + 4 of the 13, but "net." is severed on different nameservers. + + When a nameserver receives a query for (, DS, ), the + response MUST be determined from reading these rules in order: + + 1) If the nameserver is authoritative for the zone that holds the DS + RR set (i.e., the zone that delegates , a.k.a. the "parent" + zone), the response contains the DS RR set as an authoritative + answer. + + 2) If the nameserver is offering recursive service and the RD bit is + set in the query, the nameserver performs the query itself + (according to the rules for resolvers described below) and returns + its findings. + + + + +Gudmundsson Standards Track [Page 7] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + + 3) If the nameserver is authoritative for the zone that holds the + 's SOA RR set, the response is an authoritative negative + answer as described in 2.2.1.1. + + 4) If the nameserver is authoritative for a zone or zones above the + QNAME, a referral to the most enclosing (deepest match) zone's + servers is made. + + 5) If the nameserver is not authoritative for any part of the QNAME, + a response indicating a lame nameserver for QNAME is given. + + Using these rules will require some special processing on the part of + a DS RR aware resolver. To illustrate this, an example is used. + + Assuming a nameserver is authoritative for roots.example.net. and for + the root zone but not the intervening two zones (or the intervening + two label deep zone). Assume that QNAME=roots.example.net., + QTYPE=DS, and QCLASS=IN. + + The resolver will issue this request (assuming no cached data) + expecting a referral to a nameserver for .net. Instead, rule number + 3 above applies and a negative answer is returned by the nameserver. + The reaction by the resolver is not to accept this answer as final, + as it can determine from the SOA RR in the negative answer the + context within which the nameserver has answered. + + A solution would be to instruct the resolver to hunt for the + authoritative zone of the data in a brute force manner. + + This can be accomplished by taking the owner name of the returned SOA + RR and striping off enough left-hand labels until a successful NS + response is obtained. A successful response here means that the + answer has NS records in it. (Entertaining the possibility that a + cut point can be two labels down in a zone.) + + Returning to the example, the response will include a negative answer + with either the SOA RR for "roots.example.net." or "example.net." + depending on whether roots.example.net is a delegated domain. In + either case, removing the left most label of the SOA owner name will + lead to the location of the desired data. + +2.2.1.3. Modification on use of KEY RR in the construction of Responses + + This section updates RFC 2535 section 3.5 by replacing it with the + following: + + + + + + +Gudmundsson Standards Track [Page 8] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + + A query for KEY RR MUST NOT trigger any additional section + processing. Security aware resolvers will include corresponding SIG + records in the answer section. + + KEY records SHOULD NOT be added to the additional records section in + response to any query. + + RFC 2535 specified that KEY records be added to the additional + section when SOA or NS records were included in an answer. This was + done to reduce round trips (in the case of SOA) and to force out NULL + KEYs (in the NS case). As this document obsoletes NULL keys, there + is no need for the inclusion of KEYs with NSs. Furthermore, as SOAs + are included in the authority section of negative answers, including + the KEYs each time will cause redundant transfers of KEYs. + + RFC 2535 section 3.5 also included a rule for adding the KEY RRset to + the response for a query for A and AAAA types. As Restrict KEY + [RFC3445] eliminated use of KEY RR by all applications, this rule is + no longer needed. + +2.2.2. Signer's Name (replaces RFC 3008 section 2.7) + + The signer's name field of a SIG RR MUST contain the name of the zone + to which the data and signature belong. The combination of signer's + name, key tag, and algorithm MUST identify a zone key if the SIG is + to be considered material. This document defines a standard policy + for DNSSEC validation; local policy MAY override the standard policy. + + There are no restrictions on the signer field of a SIG(0) record. The + combination of signer's name, key tag, and algorithm MUST identify a + key if this SIG(0) is to be processed. + +2.2.3. Changes to RFC 3090 + + A number of sections in RFC 3090 need to be updated to reflect the DS + record. + +2.2.3.1. RFC 3090: Updates to section 1: Introduction + + Most of the text is still relevant but the words "NULL key" are to be + replaced with "missing DS RRset". In section 1.3, the last three + paragraphs discuss the confusion in sections of RFC 2535 that are + replaced in section 2.2.1 above. Therefore, these paragraphs are now + obsolete. + + + + + + + +Gudmundsson Standards Track [Page 9] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + +2.2.3.2. RFC 3090 section 2.1: Globally Secured + + Rule 2.1.b is replaced by the following rule: + + 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a + private key whose public counterpart MUST appear in a zone signing + KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to- + implement algorithm. This KEY RR MUST be identified by a DS RR in a + signed DS RRset in the parent zone. + + If a zone cannot get its parent to advertise a DS record for it, the + child zone cannot be considered globally secured. The only exception + to this is the root zone, for which there is no parent zone. + +2.2.3.3. RFC 3090 section 3: Experimental Status. + + The only difference between experimental status and globally secured + is the missing DS RRset in the parent zone. All locally secured + zones are experimental. + +2.2.4. NULL KEY elimination + + RFC 3445 section 3 eliminates the top two bits in the flags field of + KEY RR. These two bits were used to indicate NULL KEY or NO KEY. RFC + 3090 defines that zone as either secure or not and these rules + eliminate the need to put NULL keys in the zone apex to indicate that + the zone is not secured for a algorithm. Along with this document, + these other two eliminate all uses for the NULL KEY. This document + obsoletes NULL KEY. + +2.3. Comments on Protocol Changes + + Over the years, there have been various discussions surrounding the + DNS delegation model, declaring it to be broken because there is no + good way to assert if a delegation exists. In the RFC 2535 version + of DNSSEC, the presence of the NS bit in the NXT bit map proves there + is a delegation at this name. Something more explicit is required + and the DS record addresses this need for secure delegations. + + The DS record is a major change to DNS: it is the first resource + record that can appear only on the upper side of a delegation. + Adding it will cause interoperability problems and requires a flag + day for DNSSEC. Many old nameservers and resolvers MUST be upgraded + to take advantage of DS. Some old nameservers will be able to be + authoritative for zones with DS records but will not add the NXT or + DS records to the authority section. The same is true for caching + nameservers; in fact, some might even refuse to pass on the DS or NXT + records. + + + +Gudmundsson Standards Track [Page 10] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + +2.4. Wire Format of the DS record + + The DS (type=43) record contains these fields: key tag, algorithm, + digest type, and the digest of a public key KEY record that is + allowed and/or used to sign the child's apex KEY RRset. Other keys + MAY sign the child's apex KEY RRset. + + 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 (length depends on type) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (SHA-1 digest is 20 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The key tag is calculated as specified in RFC 2535. Algorithm MUST + be allowed to sign DNS data. The digest type is an identifier for + the digest algorithm used. The digest is calculated over the + canonical name of the delegated domain name followed by the whole + RDATA of the KEY record (all four fields). + + digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata) + + KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key + + Digest type value 0 is reserved, value 1 is SHA-1, and reserving + other types requires IETF standards action. For interoperability + reasons, keeping number of digest algorithms low is strongly + RECOMMENDED. The only reason to reserve additional digest types is + to increase security. + + DS records MUST point to zone KEY records that are allowed to + authenticate DNS data. The indicated KEY records protocol field MUST + be set to 3; flag field bit 7 MUST be set to 1. The value of other + flag bits is not significant for the purposes of this document. + + The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless + of key size. New digest types probably will have larger digests. + + + + + +Gudmundsson Standards Track [Page 11] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + +2.4.1. Justifications for Fields + + The algorithm and key tag fields are present to allow resolvers to + quickly identify the candidate KEY records to examine. SHA-1 is a + strong cryptographic checksum: it is computationally infeasible for + an attacker to generate a KEY record that has the same SHA-1 digest. + Combining the name of the key and the key rdata as input to the + digest provides stronger assurance of the binding. Having the key + tag in the DS record adds greater assurance than the SHA-1 digest + alone, as there are now two different mapping functions. + + This format allows concise representation of the keys that the child + will use, thus keeping down the size of the answer for the + delegation, reducing the probability of DNS message overflow. The + SHA-1 hash is strong enough to uniquely identify the key and is + similar to the PGP key footprint. The digest type field is present + for possible future expansion. + + The DS record is well suited to listing trusted keys for islands of + security in configuration files. + +2.5. Presentation Format of the DS Record + + The presentation format of the DS record consists of three numbers + (key tag, algorithm, and digest type) followed by the digest itself + presented in hex: + + example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890 + +2.6. Transition Issues for Installed Base + + No backwards compatibility with RFC 2535 is provided. + + RFC 2535-compliant resolvers will assume that all DS-secured + delegations are locally secure. This is bad, but the DNSEXT Working + Group has determined that rather than dealing with both RFC 2535- + secured zones and DS-secured zones, a rapid adoption of DS is + preferable. Thus, the only option for early adopters is to upgrade + to DS as soon as possible. + +2.6.1. Backwards compatibility with RFC 2535 and RFC 1035 + + This section documents how a resolver determines the type of + delegation. + + + + + + + +Gudmundsson Standards Track [Page 12] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + + RFC 1035 delegation (in parent) has: + + RFC 1035 NS + + RFC 2535 adds the following two cases: + + Secure RFC 2535: NS + NXT + SIG(NXT) + NXT bit map contains: NS SIG NXT + Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT) + NXT bit map contains: NS SIG KEY NXT + KEY must be a NULL key. + + DNSSEC with DS has the following two states: + + Secure DS: NS + DS + SIG(DS) + NXT bit map contains: NS SIG NXT DS + Unsecure DS: NS + NXT + SIG(NXT) + NXT bit map contains: NS SIG NXT + + It is difficult for a resolver to determine if a delegation is secure + RFC 2535 or unsecure DS. This could be overcome by adding a flag to + the NXT bit map, but only upgraded resolvers would understand this + flag, anyway. Having both parent and child signatures for a KEY + RRset might allow old resolvers to accept a zone as secure, but the + cost of doing this for a long time is much higher than just + prohibiting RFC 2535-style signatures at child zone apexes and + forcing rapid deployment of DS-enabled nameservers and resolvers. + + RFC 2535 and DS can, in theory, be deployed in parallel, but this + would require resolvers to deal with RFC 2535 configurations forever. + This document obsoletes the NULL KEY in parent zones, which is a + difficult enough change that to cause a flag day. + +2.7. KEY and corresponding DS record example + + This is an example of a KEY record and the corresponding DS record. + + dskey.example. KEY 256 3 1 ( + AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj + 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt + ) ; key id = 28668 + DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE + + + + + + + + + +Gudmundsson Standards Track [Page 13] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + +3. Resolver + +3.1. DS Example + + To create a chain of trust, a resolver goes from trusted KEY to DS to + KEY. + + Assume the key for domain "example." is trusted. Zone "example." + contains at least the following records: + example. SOA + example. NS ns.example. + example. KEY + example. NXT secure.example. NS SOA KEY SIG NXT + example. SIG(SOA) + example. SIG(NS) + example. SIG(NXT) + example. SIG(KEY) + secure.example. NS ns1.secure.example. + secure.example. DS tag=12345 alg=3 digest_type=1 + secure.example. NXT unsecure.example. NS SIG NXT DS + secure.example. SIG(NXT) + secure.example. SIG(DS) + unsecure.example NS ns1.unsecure.example. + unsecure.example. NXT example. NS SIG NXT + unsecure.example. SIG(NXT) + + In zone "secure.example." following records exist: + secure.example. SOA + secure.example. NS ns1.secure.example. + secure.example. KEY + secure.example. KEY + secure.example. NXT + secure.example. SIG(KEY) + secure.example. SIG(SOA) + secure.example. SIG(NS) + secure.example. SIG(NXT) + + In this example, the private key for "example." signs the DS record + for "secure.example.", making that a secure delegation. The DS + record states which key is expected to sign the KEY RRset at + "secure.example.". Here "secure.example." signs its KEY RRset with + the KEY identified in the DS RRset, thus the KEY RRset is validated + and trusted. + + This example has only one DS record for the child, but parents MUST + allow multiple DS records to facilitate key roll-over and multiple + KEY algorithms. + + + + +Gudmundsson Standards Track [Page 14] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + + The resolver determines the security status of "unsecure.example." by + examining the parent zone's NXT record for this name. The absence of + the DS bit indicates an unsecure delegation. Note the NXT record + SHOULD only be examined after verifying the corresponding signature. + +3.2. Resolver Cost Estimates for DS Records + + From a RFC 2535 recursive resolver point of view, for each delegation + followed to chase down an answer, one KEY RRset has to be verified. + Additional RRsets might also need to be verified based on local + policy (e.g., the contents of the NS RRset). Once the resolver gets + to the appropriate delegation, validating the answer might require + verifying one or more signatures. A simple A record lookup requires + at least N delegations to be verified and one RRset. For a DS- + enabled recursive resolver, the cost is 2N+1. For an MX record, + where the target of the MX record is in the same zone as the MX + record, the costs are N+2 and 2N+2, for RFC 2535 and DS, + respectively. In the case of a negative answer, the same ratios hold + true. + + The recursive resolver has to do an extra query to get the DS record, + which will increase the overall cost of resolving this question, but + it will never be worse than chasing down NULL KEY records from the + parent in RFC 2535 DNSSEC. + + DS adds processing overhead on resolvers and increases the size of + delegation answers, but much less than storing signatures in the + parent zone. + +4. Security Considerations + + This document proposes a change to the validation chain of KEY + records in DNSSEC. The change is not believed to reduce security in + the overall system. In RFC 2535 DNSSEC, the child zone has to + communicate keys to its parent and prudent parents will require some + authentication with that transaction. The modified protocol will + require the same authentication, but allows the child to exert more + local control over its own KEY RRset. + + There is a remote possibility that an attacker could generate a valid + KEY that matches all the DS fields, of a specific DS set, and thus + forge data from the child. This possibility is considered + impractical, as on average more than + + 2 ^ (160 - ) + + keys would have to be generated before a match would be found. + + + + +Gudmundsson Standards Track [Page 15] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + + An attacker that wants to match any DS record will have to generate + on average at least 2^80 keys. + + The DS record represents a change to the DNSSEC protocol and there is + an installed base of implementations, as well as textbooks on how to + set up secure delegations. Implementations that do not understand + the DS record will not be able to follow the KEY to DS to KEY chain + and will consider all zones secured that way as unsecure. + +5. IANA Considerations + + IANA has allocated an RR type code for DS from the standard RR type + space (type 43). + + IANA has established a new registry for the DS RR type for digest + algorithms. Defined types are: + + 0 is Reserved, + 1 is SHA-1. + + Adding new reservations requires IETF standards action. + +6. 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. + + + + + + + + +Gudmundsson Standards Track [Page 16] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + +7. Acknowledgments + + Over the last few years a number of people have contributed ideas + that are captured in this document. The core idea of using one key + to sign only the KEY RRset comes from discussions with Bill Manning + and Perry Metzger on how to put in a single root key in all + resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, + Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt + Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, + Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David + Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark + Andrews, Harald Alvestrand, and others have provided useful comments. + +8. References + +8.1. Normative References + + [RFC1035] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2535] Eastlake, D., "Domain Name System Security Extensions", + RFC 2535, March 1999. + + [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. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3445] Massey, D. and S. Rose, "Limiting the scope of the KEY + Resource Record (RR)", RFC 3445, December 2002. + +8.2. Informational References + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + + + + + +Gudmundsson Standards Track [Page 17] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + +9. Author's Address + + Olafur Gudmundsson + 3821 Village Park Drive + Chevy Chase, MD, 20815 + + EMail: ds-rfc@ogud.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gudmundsson Standards Track [Page 18] + +RFC 3658 Delegation Signer (DS) Resource Record (RR) December 2003 + + +10. 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 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 + 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. + + + + + + + + + + + + + + + + + + + +Gudmundsson Standards Track [Page 19] + diff --git a/lib/bind/port/cygwin/Makefile.in b/lib/bind/port/cygwin/Makefile.in new file mode 100644 index 0000000000..bf8977ab64 --- /dev/null +++ b/lib/bind/port/cygwin/Makefile.in @@ -0,0 +1,14 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. diff --git a/lib/bind/port/cygwin/include/Makefile.in b/lib/bind/port/cygwin/include/Makefile.in new file mode 100644 index 0000000000..f6263323a8 --- /dev/null +++ b/lib/bind/port/cygwin/include/Makefile.in @@ -0,0 +1,47 @@ +# Copyright (C) 2004 Internet Systems Consortium, Inc. ("ISC") +# Copyright (C) 2002 Internet Software Consortium. +# +# Permission to use, copy, modify, and distribute this software for any +# purpose with or without fee is hereby granted, provided that the above +# copyright notice and this permission notice appear in all copies. +# +# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH +# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY +# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, +# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM +# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE +# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR +# PERFORMANCE OF THIS SOFTWARE. + +# $Id: Makefile.in,v 1.2 2004/03/05 05:07:59 marka Exp $ + +srcdir = @srcdir@ +VPATH = @srcdir@ +top_srcdir = @top_srcdir@ + +HEADERS= ansi_realloc.h assert.h paths.h +AHEADERS= asm/socket.h +NHEADERS= net/route.h +SHEADERS= sys/bitypes.h sys/cdefs.h sys/mbuf.h sys/socket.h sys/un.h sys/wait.h + +all: + +@BIND9_MAKE_RULES@ + +installdirs: + $(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${includedir}/asm \ + ${DESTDIR}${includedir}/net ${DESTDIR}${includedir}/sys + +install:: installdirs + for i in ${HEADERS}; do \ + ${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}; \ + done + for i in ${AHEADERS}; do \ + ${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}/asm; \ + done + for i in ${NHEADERS}; do \ + ${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}/net; \ + done + for i in ${SHEADERS}; do \ + ${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}/sys; \ + done diff --git a/lib/bind/port/cygwin/include/ansi_realloc.h b/lib/bind/port/cygwin/include/ansi_realloc.h new file mode 100644 index 0000000000..24e281cc6b --- /dev/null +++ b/lib/bind/port/cygwin/include/ansi_realloc.h @@ -0,0 +1,22 @@ +/* + * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") + * Copyright (c) 1997,1999 by Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT + * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include + +#define realloc __ansi_realloc + +void *__ansi_realloc(void *ptr, size_t size); diff --git a/lib/bind/port/cygwin/include/net/route.h b/lib/bind/port/cygwin/include/net/route.h new file mode 100644 index 0000000000..5cfae5e45f --- /dev/null +++ b/lib/bind/port/cygwin/include/net/route.h @@ -0,0 +1,6 @@ +#ifndef ROUTE_H +#define ROUTE_H 1 + +/* Dummy include for CYGWIN */ + +#endif diff --git a/lib/bind/port/cygwin/include/nlist.h b/lib/bind/port/cygwin/include/nlist.h new file mode 100644 index 0000000000..4a1eea63aa --- /dev/null +++ b/lib/bind/port/cygwin/include/nlist.h @@ -0,0 +1,6 @@ +#ifndef NLIST_H +#define NLIST_H 1 + +/* Dummy include for CYGWIN */ + +#endif diff --git a/lib/bind/port/cygwin/include/sys/bitypes.h b/lib/bind/port/cygwin/include/sys/bitypes.h new file mode 100644 index 0000000000..ef3a6d4832 --- /dev/null +++ b/lib/bind/port/cygwin/include/sys/bitypes.h @@ -0,0 +1,37 @@ +/* + * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") + * Copyright (c) 1996,1999 by Internet Software Consortium. + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT + * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#ifndef __BIT_TYPES_DEFINED__ +#define __BIT_TYPES_DEFINED__ + + /* + * Basic integral types. Omit the typedef if + * not possible for a machine/compiler combination. + */ + typedef /*signed*/ char int8_t; + typedef unsigned char u_int8_t; + typedef short int16_t; + typedef unsigned short u_int16_t; + typedef int int32_t; + typedef unsigned int u_int32_t; + +# if 0 /* don't fight with these unless you need them */ + typedef long long int64_t; + typedef unsigned long long u_int64_t; +# endif + +#endif /* __BIT_TYPES_DEFINED__ */ diff --git a/lib/bind/port/cygwin/include/sys/mbuf.h b/lib/bind/port/cygwin/include/sys/mbuf.h new file mode 100644 index 0000000000..5def7e10da --- /dev/null +++ b/lib/bind/port/cygwin/include/sys/mbuf.h @@ -0,0 +1,6 @@ +#ifndef MBUF_H +#define MBUF_H 1 + +/* Dummy include for CYGWIN */ + +#endif