From d183bb19d57b948eef934fcd5fa130aaacf3eea2 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 8 Jun 2004 07:06:57 +0000 Subject: [PATCH] new draft --- .../draft-ietf-dnsext-dns-threats-06.txt | 895 ----- .../draft-ietf-dnsext-dnssec-intro-09.txt | 1401 ------- .../draft-ietf-dnsext-dnssec-protocol-05.txt | 3249 ----------------- .../draft-ietf-dnsext-dnssec-records-07.txt | 2073 ----------- doc/draft/draft-ietf-dnsext-mdns-29.txt | 1555 -------- doc/draft/draft-ietf-dnsext-nsec-rdata-05.txt | 503 --- ...-dnsop-dnssec-operational-practices-00.txt | 1288 ------- 7 files changed, 10964 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-dns-threats-06.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-records-07.txt delete mode 100644 doc/draft/draft-ietf-dnsext-mdns-29.txt delete mode 100644 doc/draft/draft-ietf-dnsext-nsec-rdata-05.txt delete mode 100644 doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt diff --git a/doc/draft/draft-ietf-dnsext-dns-threats-06.txt b/doc/draft/draft-ietf-dnsext-dns-threats-06.txt deleted file mode 100644 index 6540f0def2..0000000000 --- a/doc/draft/draft-ietf-dnsext-dns-threats-06.txt +++ /dev/null @@ -1,895 +0,0 @@ - - -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-intro-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt deleted file mode 100644 index 8097d63455..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-intro-09.txt +++ /dev/null @@ -1,1401 +0,0 @@ - - -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-dnssec-protocol-05.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt deleted file mode 100644 index 1a9f8aaf7a..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt +++ /dev/null @@ -1,3249 +0,0 @@ - - -DNS Extensions R. Arends -Internet-Draft Telematica Instituut -Expires: August 16, 2004 M. Larson - VeriSign - R. Austein - ISC - D. Massey - USC/ISI - S. Rose - NIST - February 16, 2004 - - - Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-05 - -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 document is part of a family of documents which describe the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of new resource records and protocol modifications which - add data origin authentication and data integrity to the DNS. This - document describes the DNSSEC protocol modifications. This document - - - -Arends, et al. Expires August 16, 2004 [Page 1] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - defines the concept of a signed zone, along with the requirements for - serving and resolving using DNSSEC. These techniques allow a - security-aware resolver to authenticate both DNS resource records and - authoritative DNS error indications. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 - 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1 Including DNSKEY RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.2 Including RRSIG RRs in a Zone . . . . . . . . . . . . . . . 6 - 2.3 Including NSEC RRs in a Zone . . . . . . . . . . . . . . . . 7 - 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8 - 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8 - 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 9 - 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1 Authoritative Name Servers . . . . . . . . . . . . . . . . . 10 - 3.1.1 Including RRSIG RRs in a Response . . . . . . . . . . . . . 11 - 3.1.2 Including DNSKEY RRs In a Response . . . . . . . . . . . . . 11 - 3.1.3 Including NSEC RRs In a Response . . . . . . . . . . . . . . 12 - 3.1.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 14 - 3.1.5 Responding to Queries for Type AXFR or IXFR . . . . . . . . 16 - 3.1.6 The AD and CD Bits in an Authoritative Response . . . . . . 17 - 3.2 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 17 - 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.3 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 19 - 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1 EDNS Support . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.2 Signature Verification Support . . . . . . . . . . . . . . . 20 - 4.3 Determining Security Status of Data . . . . . . . . . . . . 21 - 4.4 Preconfigured Public Keys . . . . . . . . . . . . . . . . . 22 - 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 22 - 4.6 Handling of the CD and AD bits . . . . . . . . . . . . . . . 22 - 4.7 Rate Limiting . . . . . . . . . . . . . . . . . . . . . . . 23 - 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24 - 4.8.1 Handling of the DO Bit . . . . . . . . . . . . . . . . . . . 24 - 4.8.2 Handling of the CD Bit . . . . . . . . . . . . . . . . . . . 24 - - - -Arends, et al. Expires August 16, 2004 [Page 2] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - 4.8.3 Handling of the AD Bit . . . . . . . . . . . . . . . . . . . 24 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 26 - 5.1 Special Considerations for Islands of Security . . . . . . . 27 - 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 27 - 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 28 - 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 29 - 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 30 - 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 31 - 5.3.4 Authenticating A Wildcard Expanded RRset Positive - Response . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 32 - 5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 33 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 35 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 - Normative References . . . . . . . . . . . . . . . . . . . . 37 - Informative References . . . . . . . . . . . . . . . . . . . 38 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 - A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 40 - B. Example Responses . . . . . . . . . . . . . . . . . . . . . 46 - B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 - B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 47 - B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 48 - B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 49 - B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 50 - B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 50 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 51 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 52 - C. Authentication Examples . . . . . . . . . . . . . . . . . . 54 - C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 54 - C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 54 - C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 55 - C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 55 - C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 55 - C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 55 - C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 56 - C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 56 - C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 56 - Intellectual Property and Copyright Statements . . . . . . . 57 - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 3] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) are a collection of new resource - records and protocol modifications which add data origin - authentication and data integrity to the DNS. This document defines - the DNSSEC protocol modifications. Section 2 of this document defines - the concept of a signed zone and lists the requirements for zone - signing. Section 3 describes the modifications to authoritative name - server behavior necessary to handle signed zones. Section 4 describes - the behavior of entities which include security-aware resolver - functions. Finally, Section 5 defines how to use DNSSEC RRs to - authenticate a response. - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034] and RFC1035 [RFC1035]. - - This document is part of a family of documents which define DNSSEC. - An introduction to DNSSEC and definition of common terms can be found - in [I-D.ietf-dnsext-dnssec-intro]. A definition of the DNSSEC - resource records can be found in [I-D.ietf-dnsext-dnssec-records]. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. [RFC2119]. - -1.3 Editors' Notes - -1.3.1 Open Technical Issues - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - - - - -Arends, et al. Expires August 16, 2004 [Page 4] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 5] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -2. Zone Signing - - DNSSEC introduces the concept of signed zones. A signed zone - includes DNSKEY, RRSIG, NSEC and (optionally) DS records according to - the rules specified in Section 2.1, Section 2.2, Section 2.3 and - Section 2.4, respectively. A zone that does not include these - records according to the rules in this section is an unsigned zone. - - DNSSEC requires a change to the definition of the CNAME resource - record [RFC1035]. Section 2.5 changes the CNAME RR to allow RRSIG - and NSEC RRs to appear at the same owner name as a CNAME RR. - -2.1 Including DNSKEY RRs in a Zone - - To sign a zone, the zone's administrator generates one or more - public/private key pairs and uses the private key(s) to sign - authoritative RRsets in the zone. For each private key used to - create RRSIG RRs, there SHOULD be a corresponding zone DNSKEY RR with - the public component stored in the zone. A zone key DNSKEY RR MUST - have the Zone Key bit of the flags RDATA field set to one -- see - Section 2.1.1 of [I-D.ietf-dnsext-dnssec-records]. Public keys - associated with other DNS operations MAY be stored in DNSKEY RRs that - are not marked as zone keys but MUST NOT be used to verify RRSIGs. - - If the zone is delegated and does not wish to act as an island of - security, the zone MUST have at least one DNSKEY RR at the apex to - act as a secure entry point into the zone. This DNSKEY would then be - used to generate a DS RR at the delegating parent (see - [I-D.ietf-dnsext-dnssec-records]). - - DNSKEY RRs MUST NOT appear at delegation points. - -2.2 Including RRSIG RRs in a Zone - - For each authoritative RRset in a signed zone, there MUST be at least - one RRSIG record that meets all of the following requirements: - - o The RRSIG owner name is equal to the RRset owner name; - - o The RRSIG class is equal to the RRset class; - - o The RRSIG Type Covered field is equal to the RRset type; - - o The RRSIG Original TTL field is equal to the TTL of the RRset; - - o The RRSIG RR's TTL is equal to the TTL of the RRset; - - o The RRSIG Labels field is equal to the number of labels in the - - - -Arends, et al. Expires August 16, 2004 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - RRset owner name, not counting the null root label and not - counting the leftmost label if it is a wildcard; - - o The RRSIG Signer's Name field is equal to the name of the zone - containing the RRset; and - - o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a - zone key DNSKEY record at the zone apex. - - The process for constructing the RRSIG RR for a given RRset is - described in [I-D.ietf-dnsext-dnssec-records]. An RRset MAY have - multiple RRSIG RRs associated with it. - - An RRSIG RR itself MUST NOT be signed, since signing an RRSIG RR - would add no value and would create an infinite loop in the signing - process. - - The NS RRset that appears at the zone apex name MUST be signed, but - the NS RRsets that appear at delegation points (that is, the NS - RRsets in the parent zone that delegate the name to the child zone's - name servers) MUST NOT be signed. Glue address RRsets associated with - delegations MUST NOT be signed. - - There MUST be an RRSIG for each RRset using at least one DNSKEY of - each algorithm in the parent zone's DS RRset and each additional - algorithm, if any, in the apex DNSKEY RRset. The apex DNSKEY RRset - itself MUST be signed by each algorithm appearing in the DS RRset. - -2.3 Including NSEC RRs in a Zone - - Each owner name in the zone which has authoritative data or a - delegation point NS RRset MUST have an NSEC resource record. The - process for constructing the NSEC RR for a given name is described in - [I-D.ietf-dnsext-dnssec-records]. - - The TTL value for any NSEC RR SHOULD be the same as the minimum TTL - value field in the zone SOA RR. - - An NSEC record (and its associated RRSIG RRset) MUST NOT be the only - RRset at any particular owner name. That is, the signing process - MUST NOT create NSEC or RRSIG RRs for owner names nodes which were - not the owner name of any RRset before the zone was signed. - - The type bitmap of every NSEC resource record in a signed zone MUST - indicate the presence of both the NSEC record itself and its - corresponding RRSIG record. - - The difference between the set of owner names that require RRSIG - - - -Arends, et al. Expires August 16, 2004 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - records and the set of owner names that require NSEC records is - subtle and worth highlighting. RRSIG records are present at the - owner names of all authoritative RRsets. NSEC records are present at - the owner names of all names for which the signed zone is - authoritative and also at the owner names of delegations from the - signed zone to its children. Neither NSEC nor RRSIG records are - present (in the parent zone) at the owner names of glue address - RRsets. Note, however, that this distinction is for the most part is - only visible during the zone signing process, because NSEC RRsets are - authoritative data, and are therefore signed, thus any owner name - which has an NSEC RRset will have RRSIG RRs as well in the signed - zone. - -2.4 Including DS RRs in a Zone - - The DS resource record establishes authentication chains between DNS - zones. A DS RRset SHOULD be present at a delegation point when the - child zone is signed. The DS RRset MAY contain multiple records, - each referencing a public key in the child zone used to verify the - RRSIGs in that zone. All DS RRsets in a zone MUST be signed and DS - RRsets MUST NOT appear at a zone's apex. - - A DS RR SHOULD point to a DNSKEY RR which is present in the child's - apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed - by the corresponding private key. - - The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset - (i.e., the NS RRset from the same zone containing the DS RRset). - - Construction of a DS RR requires knowledge of the corresponding - DNSKEY RR in the child zone, which implies communication between the - child and parent zones. This communication is an operational matter - not covered by this document. - -2.5 Changes to the CNAME Resource Record. - - If a CNAME RRset is present at a name in a signed zone, appropriate - RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that - name for secure dynamic update purposes is also allowed. Other types - MUST NOT be present at that name. - - This is a modification to the original CNAME definition given in - [RFC1034]. The original definition of the CNAME RR did not allow any - other types to coexist with a CNAME record, but a signed zone - requires NSEC and RRSIG RRs for every authoritative name. To resolve - this conflict, this specification modifies the definition of the - CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. - - - - -Arends, et al. Expires August 16, 2004 [Page 8] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -2.6 Example of a Secure Zone - - Appendix A shows a complete example of a small signed zone. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 9] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -3. Serving - - This section describes the behavior of entities that include - security-aware name server functions. In many cases such functions - will be part of a security-aware recursive name server, but a - security-aware authoritative name server has some of the same - requirements as a security-aware recursive name server does. - Functions specific to security-aware recursive name servers are - described in Section 3.2; functions specific to authoritative servers - are described in Section 3.1. - - The terms "SNAME", "SCLASS", and "STYPE" in the following discussion - are as used in [RFC1034]. - - A security-aware name server MUST support the EDNS0 [RFC2671] message - size extension, MUST support a message size of at least 1220 octets, - and SHOULD support a message size of 4000 octets [RFC3226]. - - A security-aware name server that receives a DNS query that does not - include the EDNS OPT pseudo-RR or that has the DO bit set to zero - MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other - RRset, and MUST NOT perform any of the additional processing - described below. Since the DS RR type has the peculiar property of - only existing in the parent zone at delegation points, DS RRs always - require some special processing, as described in Section 3.1.4.1. - - DNSSEC allocates two new bits in the DNS message header: the CD - (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit - is controlled by resolvers; a security-aware name server MUST copy - the CD bit from a query into the corresponding response. The AD bit - is controlled by name servers; a security-aware name server MUST - ignore the setting of the AD bit in queries. See Section 3.1.6, - Section 3.2.2, Section 3.2.3, Section 4, and Section 4.8 for details - on the behavior of these bits. - -3.1 Authoritative Name Servers - - Upon receiving a relevant query that has the EDNS [RFC2671] OPT - pseudo-RR DO bit [RFC3225] set to one, a security-aware authoritative - name server for a signed zone MUST include additional RRSIG, NSEC, - and DS RRs according to the following rules: - - o RRSIG RRs that can be used to authenticate a response MUST be - included in the response according to the rules in Section 3.1.1; - - o NSEC RRs that can be used to provide authenticated denial of - existence MUST be included in the response automatically according - to the rules in Section 3.1.3; - - - -Arends, et al. Expires August 16, 2004 [Page 10] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST - be included in referrals automatically according to the rules in - Section 3.1.4. - - DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 - discusses zone transfer requirements. - -3.1.1 Including RRSIG RRs in a Response - - When responding to a query that has the DO bit set to one, a - security-aware authoritative name server SHOULD attempt to send RRSIG - RRs that a security-aware resolver can use to authenticate the RRsets - in the response. Inclusion of RRSIG RRs in a response is subject to - the following rules: - - o When placing a signed RRset in the Answer section, the name server - MUST also place its RRSIG RRs in the Answer section. The RRSIG - RRs have a higher priority for inclusion than any other RRsets - that may need to be included. If space does not permit inclusion - of these RRSIG RRs, the name server MUST set the TC bit. - - o When placing a signed RRset in the Authority section, the name - server MUST also place its RRSIG RRs in the Authority section. - The RRSIG RRs have a higher priority for inclusion than any other - RRsets that may need to be included. If space does not permit - inclusion of these RRSIG RRs, the name server MUST set the TC bit. - - o When placing a signed RRset in the Additional section, the name - server MUST also place its RRSIG RRs in the Additional section. - If space does not permit inclusion of both the RRset and its - associated RRSIG RRs, the name server MUST NOT set the TC bit - solely because these RRSIG RRs didn't fit. - - -3.1.2 Including DNSKEY RRs In a Response - - When responding to a query that has the DO bit set to one and that - requests the SOA or NS RRs at the apex of a signed zone, a - security-aware authoritative name server for that zone MAY return the - zone apex DNSKEY RRset in the Additional section. In this situation, - the DNSKEY RRset and associated RRSIG RRs have lower priority than - any other information that would be placed in the additional section. - The name server SHOULD NOT include the DNSKEY RRset unless there is - enough space in the response message for both the DNSKEY RRset and - its associated RRSIG RR(s). If there is not enough space to include - these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST - NOT set the TC bit solely because these RRs didn't fit (see Section - 3.1.1). - - - -Arends, et al. Expires August 16, 2004 [Page 11] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -3.1.3 Including NSEC RRs In a Response - - When responding to a query that has the DO bit set to one, a - security-aware authoritative name server for a signed zone MUST - include NSEC RRs in each of the following cases: - - No Data: The zone contains RRsets that exactly match , - but does not contain any RRsets that exactly match . - - Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. - - Wildcard Answer: The zone does not contain any RRsets that exactly - match but does contain an RRset that matches - via wildcard name expansion. - - Wildcard No Data: The zone does not contain any RRsets that exactly - match , does contain one or more RRsets that match - via wildcard name expansion, but does not contain - any RRsets that match via wildcard name - expansion. - - In each of these cases, the name server includes NSEC RRs in the - response to prove that an exact match for was - not present in the zone and that the response that the name server is - returning is correct given the data that are in the zone. - -3.1.3.1 Including NSEC RRs: No Data Response - - If the zone contains RRsets matching but contains no - RRset matching , then the name server MUST - include the NSEC RR for along with its associated - RRSIG RR(s) in the Authority section of the response (see Section - 3.1.1). If space does not permit inclusion of the NSEC RR or its - associated RRSIG RR(s), the name server MUST set the TC bit (see - Section 3.1.1). - - Since the search name exists, wildcard name expansion does not apply - to this query, and a single signed NSEC RR suffices to prove the - requested RR type does not exist. - -3.1.3.2 Including NSEC RRs: Name Error Response - - If the zone does not contain any RRsets matching - either exactly or via wildcard name expansion, then the name server - MUST include the following NSEC RRs in the Authority section, along - with their associated RRSIG RRs: - - - -Arends, et al. Expires August 16, 2004 [Page 12] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o An NSEC RR proving that there is no exact match for ; and - - o An NSEC RR proving that the zone contains no RRsets that would - match via wildcard name expansion. - - In some cases a single NSEC RR may prove both of these points, in - that case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - Note that this form of response includes cases in which SNAME - corresponds to an empty non-terminal name within the zone (a name - which is not the owner name for any RRset but which is the parent - name of one or more RRsets). - -3.1.3.3 Including NSEC RRs: Wildcard Answer Response - - If the zone does not contain any RRsets which exactly match but does contain an RRset which matches via wildcard name expansion, the name server MUST include the - wildcard-expanded answer and the corresponding wildcard-expanded - RRSIG RRs in the Answer section, and MUST include in the Authority - section an NSEC RR and associated RRSIG RR(s) proving that the zone - does not contain a closer match for . If space does - not permit inclusion of the answer, NSEC and RRSIG RRs, the name - server MUST set the TC bit (see Section 3.1.1). - -3.1.3.4 Including NSEC RRs: Wildcard No Data Response - - This case is a combination of the previous cases. The zone does not - contain an exact match for , and while the zone does - contain RRsets which match via wildcard expansion, - none of those RRsets match STYPE. The name server MUST include the - following NSEC RRs in the Authority section, along with their - associated RRSIG RRs: - - o An NSEC RR proving that there are no RRsets matching STYPE at the - wildcard owner name which matched via wildcard - expansion; and - - o An NSEC RR proving that there are no RRsets in the zone which - - - -Arends, et al. Expires August 16, 2004 [Page 13] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - would have been a closer match for . - - In some cases a single NSEC RR may prove both of these points, in - which case the name server SHOULD only include the NSEC RR and its - RRSIG RR(s) once in the Authority section. - - The owner names of these NSEC and RRSIG RRs are not subject to - wildcard name expansion when these RRs are included in the Authority - section of the response. - - If space does not permit inclusion of these NSEC and RRSIG RRs, the - name server MUST set the TC bit (see Section 3.1.1). - -3.1.3.5 Finding The Right NSEC RRs - - As explained above, there are several situations in which a - security-aware authoritative name server needs to locate an NSEC RR - which proves that a particular SNAME does not exist. Locating such - an NSEC RR within an authoritative zone is relatively simple, at - least in concept. The following discussion assumes that the name - server is authoritative for the zone which would have held the - nonexistent SNAME. The algorithm below is written for clarity, not - efficiency. - - To find the NSEC which proves that name N does not exist in the zone - Z which would have held it, construct sequence S consisting of every - name in Z, sorted into canonical order - [I-D.ietf-dnsext-dnssec-records]. Find the name M which would have - immediately preceded N in S if N had existed. M is the owner name of - the NSEC RR which proves that N does not exist. - - The algorithm for finding the NSEC RR which proves that a given name - is not covered by any applicable wildcard is similar, but requires an - extra step. More precisely, the algorithm for finding the NSEC - proving that the applicable wildcard name does not exist is precisely - the same as the algorithm for finding the NSEC RR which proves that - any other name does not exist: the part that's missing is how to - determine the name of the nonexistent applicable wildcard. In - practice, this is easy, because the authoritative name server has - already checked for the presence of precisely this wildcard name as - part of step (1)(c) of the normal lookup algorithm described in - Section 4.3.2 of [RFC1034]. - -3.1.4 Including DS RRs In a Response - - When responding to a query which has the DO bit set to one, a - security-aware authoritative name server returning a referral - includes DNSSEC data along with the NS RRset. - - - -Arends, et al. Expires August 16, 2004 [Page 14] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - If a DS RRset is present at the delegation point, the name server - MUST return both the DS RRset and its associated RRSIG RR(s) in the - Authority section along with the NS RRset. The name server MUST - place the NS RRset before the DS RRset and its associated RRSIG - RR(s). - - If no DS RRset is present at the delegation point, the name server - MUST return both the NSEC RR which proves that the DS RRset is not - present and the NSEC RR's associated RRSIG RR(s) along with the NS - RRset. The name server MUST place the NS RRset before the NSEC RRset - and its associated RRSIG RR(s). - - Including these DS, NSEC, and RRSIG RRs increases the size of - referral messages, and may cause some or all glue RRs to be omitted. - If space does not permit inclusion of the DS or NSEC RRset and - associated RRSIG RRs, the name server MUST set the TC bit (see - Section 3.1.1). - -3.1.4.1 Responding to Queries for DS RRs - - The DS resource record type is unusual in that it appears only on the - parent zone's side of a zone cut. For example, the DS RRset for the - delegation of "foo.example" is stored in the "example" zone rather - than in the "foo.example" zone. This requires special processing - rules for both name servers and resolvers, since the name server for - the child zone is authoritative for the name at the zone cut by the - normal DNS rules but the child zone does not contain the DS RRset. - - A security-aware resolver sends queries to the parent zone when - looking for a needed DS RR at a delegation point (see Section 4.2). - However, special rules are necessary to avoid confusing - security-oblivious resolvers which might become involved in - processing such a query (for example, in a network configuration that - forces a security-aware resolver to channel its queries through a - security-oblivious recursive name server). The rest of this section - describes how a security-aware name server processes DS queries in - order to avoid this problem. - - The need for special processing by a security-aware name server only - arises when all the following conditions are met: - - o the name server has received a query for the DS RRset at a zone - cut; and - - o the name server is authoritative for the child zone; and - - o the name server is not authoritative for the parent zone; and - - - - -Arends, et al. Expires August 16, 2004 [Page 15] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o the name server does not offer recursion. - - In all other cases, the name server either has some way of obtaining - the DS RRset or could not have been expected to have the DS RRset - even by the pre-DNSSEC processing rules, so the name server can - return either the DS RRset or an error response according to the - normal processing rules. - - If all of the above conditions are met, however, the name server is - authoritative for SNAME but cannot supply the requested RRset. In - this case, the name server MUST return an authoritative "no data" - response showing that the DS RRset does not exist in the child zone's - apex. See Appendix B.8 for an example of such a response. - -3.1.5 Responding to Queries for Type AXFR or IXFR - - DNSSEC does not change the DNS zone transfer process. A signed zone - will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these - records have no special meaning with respect to a zone transfer - operation, and these RRs are treated as any other resource record - type. - - An authoritative name server is not required to verify that a zone is - properly signed before sending or accepting a zone transfer. - However, an authoritative name server MAY choose to reject the entire - zone transfer if the zone fails meets any of the signing requirements - described in Section 2. The primary objective of a zone transfer is - to ensure that all authoritative name servers have identical copies - of the zone. An authoritative name server which chooses to perform - its own zone validation MUST NOT selectively reject some RRs and - accept others. - - DS RRsets appear only on the parental side of a zone cut and are - authoritative data in the parent zone. As with any other - authoritative RRset, the DS RRset MUST be included in zone transfers - of the zone in which the RRset is authoritative data: in the case of - the DS RRset, this is the parent zone. - - NSEC RRs appear in both the parent and child zones at a zone cut, and - are authoritative data in both the parent and child zones. The - parental and child NSEC RRs at a zone cut are never identical to each - other, since the NSEC RR in the child zone's apex will always - indicate the presence of the child zone's SOA RR while the parental - NSEC RR at the zone cut will never indicate the presence of an SOA - RR. As with any other authoritative RRs, NSEC RRs MUST be included - in zone transfers of the zone in which they are authoritative data: - the parental NSEC RR at a zone cut MUST be included zone transfers of - the parent zone, while the NSEC at the zone apex of the child zone - - - -Arends, et al. Expires August 16, 2004 [Page 16] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - MUST be included in zone transfers of the child zone. - - RRSIG RRs appear in both the parent and child zones at a zone cut, - and are authoritative in whichever zone contains the authoritative - RRset for which the RRSIG RR provides the signature. That is, the - RRSIG RR for a DS RRset or a parental NSEC RR at a zone cut will be - authoritative in the parent zone, while the RRSIG for any RRset in - the child zone's apex will be authoritative in the child zone. As - with any other authoritative RRs, RRSIG RRs MUST be included in zone - transfers of the zone in which they are authoritative data. - -3.1.6 The AD and CD Bits in an Authoritative Response - - The CD and AD bits are designed to be used in communication between - security-aware resolvers and security-aware recursive name servers. - This bits are for the most part not relevant to query processing by - security-aware authoritative name servers. - - Since a security-aware name server does not perform signature - validation for authoritative data during query processing even when - the CD bit is set to zero, a security-aware name server SHOULD ignore - the setting of the CD bit when composing an authoritative response. - - A security-aware name server MUST NOT set the AD bit in a response - unless the name server considers all RRsets in the Answer and - Authority sections of the response to be authentic. A security-aware - name server's local policy MAY consider data from an authoritative - zone to be authentic without further validation, but the name server - MUST NOT do so unless the name server obtained the authoritative zone - via secure means (such as a secure zone transfer mechanism), and MUST - NOT do so unless this behavior has been configured explicitly. - - A security-aware name server which supports recursion MUST follow the - rules for the CD and AD bits given in Section 3.2 when generating a - response that involves data obtained via recursion. - -3.2 Recursive Name Servers - - As explained in [I-D.ietf-dnsext-dnssec-intro], a security-aware - recursive name server is an entity which acts in both the - security-aware name server and security-aware resolver roles. This - section uses the terms "name server side" and "resolver side" to - refer to the code within a security-aware recursive name server which - implements the security-aware name server role and the code which - implements the security-aware resolver role, respectively. - - The resolver side follows the usual rules for caching and negative - caching which would apply to any security-aware resolver. - - - -Arends, et al. Expires August 16, 2004 [Page 17] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -3.2.1 The DO bit - - The resolver side of a security-aware recursive name server MUST set - the DO bit when sending requests, regardless of the state of the DO - bit in the initiating request received by the name server side. If - the DO bit in an initiating query is not set, the name server side - MUST strip any authenticating DNSSEC RRs from the response, but MUST - NOT strip any DNSSEC RRs that the initiating query explicitly - requested. - -3.2.2 The CD bit - - The CD bit exists in order to allow a security-aware resolver to - disable signature validation in a security-aware name server's - processing of a particular query. - - The name server side MUST copy the setting of the CD bit from a query - to the corresponding response. - - The name server side of a security-aware recursive name server MUST - pass the sense of the CD bit to the resolver side along with the rest - of an initiating query, so that the resolver side will know whether - or not it is required to verify the response data it returns to the - name server side. If the CD bit is set to one, it indicates that the - originating resolver is willing to perform whatever authentication - its local policy requires, thus the resolver side of the recursive - name server need not perform authentication on the RRsets in the - response. When the CD bit is set to one the recursive name server - SHOULD, if possible, return the requested data to the originating - resolver even if the recursive name server's local authentication - policy would reject the records in question. That is, by setting the - CD bit, the originating resolver has indicated that it takes - responsibility for performing its own authentication, and the - recursive name server should not interfere. - - If the resolver side implements a BAD cache (see Section 4.7) and the - name server side receives a query which matches an entry in the - resolver side's BAD cache, the name server side's response depends on - the sense of the CD bit in the original query. If the CD bit is set, - the name server side SHOULD return the data from the BAD cache; if - the CD bit is not set, the name server side MUST return RCODE 2 - (server failure). - -3.2.3 The AD bit - - The name server side of a security-aware recursive name server MUST - NOT set the AD bit in a response unless the name server considers all - RRsets in the Answer and Authority sections of the response to be - - - -Arends, et al. Expires August 16, 2004 [Page 18] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - authentic, and SHOULD set the AD bit if and only if the resolver side - considers all RRsets in the Answer section and any relevant negative - response RRs in the Authority section to be authentic. The resolver - side MUST follow the procedure described in Section 5 to determine - whether the RRs in question are authentic. - -3.3 Example DNSSEC Responses - - See Appendix B for example response packets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 19] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -4. Resolving - - This section describes the behavior of entities which include - security-aware resolver functions. In many cases such functions will - be part of a security-aware recursive name server, but a stand-alone - security-aware resolver has many of the same requirements. Functions - specific to security-aware recursive name servers are described in - Section 3.2. - -4.1 EDNS Support - - A security-aware resolver MUST include an EDNS [RFC2671] OPT - pseudo-RR with the DO [RFC3225] bit set to one when sending queries. - - A security-aware resolver MUST support a message size of at least - 1220 octets, SHOULD support a message size of 4000 octets, and MUST - advertise the supported message size using the "sender's UDP payload - size" field in the EDNS OPT pseudo-RR. A security-aware resolver MUST - handle fragmented UDP packets correctly regardless of whether any - such fragmented packets were received via IPv4 or IPv6. Please see - [RFC3226] for discussion of these requirements. - -4.2 Signature Verification Support - - A security-aware resolver MUST support the signature verification - mechanisms described in Section 5, and MUST apply them to every - received response except when: - - o The security-aware resolver is part of a security-aware recursive - name server, and the response is the result of recursion on behalf - of a query received with the CD bit set; - - o The response is the result of a query generated directly via some - form of application interface which instructed the security-aware - resolver not to perform validation for this query; or - - o Validation for this query has been disabled by local policy. - - A security-aware resolver's support for signature verification MUST - include support for verification of wildcard owner names. - - Editors' note: The rest of this section is expected to change once - the WG reaches closure on Q-23. - - A security-aware resolver MUST attempt to retrieve missing DS, - DNSKEY, or RRSIG RRs via explicit queries if the resolver needs these - RRs in order to perform signature verification. - - - - -Arends, et al. Expires August 16, 2004 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - A security-aware resolver MUST attempt to retrieve a missing NSEC RR - which the resolver needs to authenticate a NODATA response. In - general it is not possible for a resolver to retrieve missing NSEC - RRs, since the resolver will have no way of knowing the owner name of - the missing NSEC RR, but in the specific case of a NODATA response, - the resolver may know the name of the missing NSEC RR, and in such - cases must therefore attempt to retrieve it. - - When attempting to retrieve missing NSEC RRs which reside on the - parental side at a zone cut, a security-aware iterative-mode resolver - MUST query the name servers for the parent zone, not the child zone. - - When attempting to retrieve a missing DS, a security-aware - iterative-mode resolver MUST query the name servers for the parent - zone, not the child zone. As explained in Section 3.1.4.1, - security-aware name servers need to apply special processing rules to - handle the DS RR, and in some situations the resolver may also need - to apply special rules to locate the name servers for the parent zone - if the resolver does not already have the parent's NS RRset. To - locate the parent NS RRset, the resolver can start with the - delegation name, strip off the leftmost label, and query for an NS - RRset by that name; if no NS RRset is present at that name, the - resolver then strips of the leftmost remaining label and retries the - query for that name, repeating this process of walking up the tree - until it either finds the NS RRset or runs out of labels. - - Editors' note: This algorithm could easily be read as an - invitation to careless implementors to hammer the root zone - servers. Better wording would be welcome. - - -4.3 Determining Security Status of Data - - Editors' note: This section is waiting for resolution of Q-28. - - A security-aware resolver MUST be able to determine whether or not it - should expect a particular RRset to be signed. More precisely, a - security-aware resolver must be able to distinguish between three - cases: - - 1. An RRset for which the resolver is able to build a chain of - signed DNSKEY and DS RRs from a trusted security anchor to the - RRset. In this case, the RRset should be signed, and is subject - to signature validation as described above. - - 2. An RRset for which the resolver knows that it has no chain of - signed DNSKEY and DS RRs from any trusted starting point to the - RRset. This can occur when the target RRset lies in an unsigned - - - -Arends, et al. Expires August 16, 2004 [Page 21] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - zone or in a descendent of an unsigned zone. In this case, the - RRset may or may not be signed, but the resolver will not be able - to verify the signature. - - 3. An RRset for which the resolver is not able to determine whether - or not the RRset should be signed, because the resolver is not - able to obtain the necessary DNSSEC RRs. This can occur when the - security-aware resolver is not able to contact security-aware - name servers for the relevant zones. - - -4.4 Preconfigured Public Keys - - A security-aware resolver MUST be capable of being preconfigured with - at least one trusted public key or DS RR, and SHOULD be capable of - being preconfigured with multiple trusted public keys or DS RRs. - Since a security-aware resolver will not be able to validate - signatures without such a preconfigured trusted key, the resolver - SHOULD have some reasonably robust mechanism for obtaining such keys - when it boots; examples of such a mechanism would be some form of - non-volatile storage (such as a disk drive) or some form of trusted - local network configuration mechanism. - -4.5 Response Caching - - Editors' note: RIPE "last call" workshop felt that the WG needs to - reexamine and discuss this section. - - A security-aware resolver SHOULD cache each response as a single - atomic entry containing the entire answer, including the named RRset - and any associated DNSSEC RRs. The resolver SHOULD discard the - entire atomic entry when any of the RRs contained in it expire. In - most cases the appropriate cache index for the atomic entry will be - the triple , but in cases such as the response - form described in Section 3.1.3.2 the appropriate cache index will be - the double . - -4.6 Handling of the CD and AD bits - - A security-aware resolver MAY set the CD bit in a query to one in - order to indicate that the resolver takes responsibility for - performing whatever authentication its local policy requires on the - RRsets in the response. See Section 3.2 for the effect this bit has - on the behavior of security-aware recursive name servers. - - A security-aware resolver MUST zero the AD bit when composing query - messages to protect against buggy name servers which blindly copy - header bits which they do not understand from the query message to - - - -Arends, et al. Expires August 16, 2004 [Page 22] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - the response message. - - A resolver MUST disregard the meaning of the CD and AD bits in a - response unless the response was obtained using a secure channel or - the resolver was specifically configured to regard the message header - bits without using a secure channel. - -4.7 Rate Limiting - - A security-aware resolver SHOULD NOT cache data with invalid - signatures under normal circumstances. However, a security-aware - resolver SHOULD take steps to rate limit the number of identical - queries that it generates if signature validation of the responses - fails repeatedly. - - Conceptually, this is similar in some respects to negative caching - [RFC2308], but since the resolver has no way of obtaining an - appropriate caching TTL from received data in this case, the TTL will - have to be set by the implementation. This document refers to the - data retained as part of such a rate limiting mechanism as the "BAD - cache". - - A security-aware resolver MAY chose to retain RRsets for which - signature validation has failed in its BAD cache, but MUST NOT return - such RRsets from its BAD cache unless both of the following - conditions are met: - - o The resolver has recently generated enough queries identical to - this one that the resolver is suppressing queries for this ; and - - o The resolver is not required to validate the signatures of the - RRsets in question under the rules given in Section 4 of this - document. - - The intent of the above rule is to provide the raw data to clients - which are capable of performing their own signature verification - checks while protecting clients which depend on this resolver to - perform such checks. Several of the possible reasons why signature - validation might fail involve conditions which may not apply equally - to this resolver and the client which invoked it: for example, this - resolver's clock may be set incorrectly, or the client may have - knowledge of a relevant island of security which this resolver does - not share. In such cases, "protecting" a client which is capable of - performing its own signature validation from ever seeing the "bad" - data does not help the client. - - - - - -Arends, et al. Expires August 16, 2004 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -4.8 Stub resolvers - - A security-aware stub resolver MUST support the DNSSEC RR types, at - least to the extent of not mishandling responses just because they - contain DNSSEC RRs. - -4.8.1 Handling of the DO Bit - - A non-validating security-aware stub resolver MAY include the DNSSEC - RRs returned by a security-aware recursive name server as part of the - data that the stub resolver hands back to the application which - invoked it but is not required to do so. A non-validating stub - resolver that wishes to do this will need to set the DO bit in - receive DNSSEC RRs from the recursive name server. - - A validating security-aware stub resolver MUST set the DO bit, since - otherwise it will not receive the DNSSEC RRs it needs to perform - signature validation. - -4.8.2 Handling of the CD Bit - - A non-validating security-aware stub resolver SHOULD NOT set the CD - bit when sending queries unless requested by the application layer, - since by definition, a non-validating stub resolver depends on the - security-aware recursive name server to perform validation on its - behalf. - - A validating security-aware stub resolver SHOULD set the CD bit, - since otherwise the security-aware recursive name server will answer - the query using the name server's local policy, which may prevent the - stub resolver from receiving data which would be acceptable to the - stub resolver's local policy. - -4.8.3 Handling of the AD Bit - - A non-validating security-aware stub resolver MAY chose to examine - the setting of the AD bit in response messages that it receives in - order to determine whether the security-aware recursive name server - which sent the response claims to have cryptographically verified the - data in the Answer and Authority sections of the response message. - Note, however, that the responses received by a security-aware stub - resolver are heavily dependent on the local policy of the - security-aware recursive name server, so as a practical matter there - may be little practical value to checking the status of the AD bit - except perhaps as a debugging aid. In any case, a security-aware - stub resolver MUST NOT place any reliance on signature validation - allegedly performed on its behalf except when the security-aware stub - resolver obtained the data in question from a trusted security-aware - - - -Arends, et al. Expires August 16, 2004 [Page 24] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - recursive name server via a secure channel. - - A validating security-aware stub resolver SHOULD NOT examine the - setting of the AD bit in response messages, since, by definition, the - stub resolver performs its own signature validation regardless of the - setting of the AD bit. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 25] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -5. Authenticating DNS Responses - - In order to use DNSSEC RRs for authentication, a security-aware - resolver requires preconfigured knowledge of at least one - authenticated DNSKEY or DS RR. The process for obtaining and - authenticating this initial DNSKEY or DS RR is achieved via some - external mechanism. For example, a resolver could use some off-line - authenticated exchange to obtain a zone's DNSKEY RR or obtain a DS RR - that identifies and authenticates a zone's DNSKEY RR. The remainder - of this section assumes that the resolver has somehow obtained an - initial set of authenticated DNSKEY RRs. - - An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY - RRset. To authenticate an apex DNSKEY RRset using an initial key, - the resolver MUST: - - 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR MUST have the Zone Key Flag - (DNSKEY RDATA bit 7) set to one. - - 2. Verify that there is some RRSIG RR that covers the apex DNSKEY - RRset, and that the combination of the RRSIG RR and the initial - DNSKEY RR authenticates the DNSKEY RRset. The process for using - an RRSIG RR to authenticate an RRset is described in Section 5.3. - - Once the resolver has authenticated the apex DNSKEY RRset using an - initial DNSKEY RR, delegations from that zone can be authenticated - using DS RRs. This allows a resolver to start from an initial key, - and use DS RRsets to proceed recursively down the DNS tree obtaining - other apex DNSKEY RRsets. If the resolver were preconfigured with a - root DNSKEY RR, and if every delegation had a DS RR associated with - it, then the resolver could obtain and validate any apex DNSKEY - RRset. The process of using DS RRs to authenticate referrals is - described in Section 5.2. - - Once the resolver has authenticated a zone's apex DNSKEY RRset, - Section 5.3 shows how the resolver can use DNSKEY RRs in the apex - DNSKEY RRset and RRSIG RRs from the zone to authenticate any other - RRsets in the zone. Section 5.4 shows how the resolver can use - authenticated NSEC RRsets from the zone to prove that an RRset is not - present in the zone. - - When a resolver indicates support for DNSSEC (by setting the DO bit), - a security-aware name server should attempt to provide the necessary - DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). - However, a security-aware resolver may still receive a response that - that lacks the appropriate DNSSEC RRs, whether due to configuration - issues such as a security-oblivious recursive name server that - - - -Arends, et al. Expires August 16, 2004 [Page 26] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - accidentally interfere with DNSSEC RRs or due to a deliberate attack - in which an adversary forges a response, strips DNSSEC RRs from a - response, or modifies a query so that DNSSEC RRs appear not to be - requested. The absence of DNSSEC data in a response MUST NOT by - itself be taken as an indication that no authentication information - exists. - - A resolver SHOULD expect authentication information from signed - zones. A resolver SHOULD believe that a zone is signed if the - resolver has been configured with public key information for the - zone, or if the zone's parent is signed and the delegation from the - parent contains a DS RRset. - -5.1 Special Considerations for Islands of Security - - Islands of security (see [I-D.ietf-dnsext-dnssec-intro]) are signed - zones for which it is not possible to construct an authentication - chain to the zone from its parent. Validating signatures within an - island of security requires the validator to have some other means of - obtaining an initial authenticated zone key for the island. If a - validator cannot obtain such a key, it will have to choose whether to - accept the unvalidated responses or not based on local policy. - - All the normal processes for validating responses apply to islands of - security. The only difference between normal validation and - validation within an island of security is in how the validator - obtains a starting point for the authentication chain. - -5.2 Authenticating Referrals - - Once the apex DNSKEY RRset for a signed parent zone has been - authenticated, DS RRsets can be used to authenticate the delegation - to a signed child zone. A DS RR identifies a DNSKEY RR in the child - zone's apex DNSKEY RRset, and contains a cryptographic digest of the - child zone's DNSKEY RR. A strong cryptographic digest algorithm - ensures that an adversary can not easily generate a DNSKEY RR that - matches the digest. Thus, authenticating the digest allows a - resolver to authenticate the matching DNSKEY RR. The resolver can - then use this child DNSKEY RR to authenticate the entire child apex - DNSKEY RRset. - - Given a DS RR for a delegation, the child zone's apex DNSKEY RRset - can be authenticated if all of the following hold: - - o The DS RR has been authenticated using some DNSKEY RR in the - parent's apex DNSKEY RRset (see Section 5.3); - - o The Algorithm and Key Tag in the DS RR match the Algorithm field - - - -Arends, et al. Expires August 16, 2004 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - and the key tag of a DNSKEY RR in the child zone's apex DNSKEY - RRset that, when hashed using the digest algorithm specified in - the DS RR's Digest Type field, results in a digest value that - matches the Digest field of the DS RR; and - - o The matching DNSKEY RR in the child zone has the Zone Flag bit set - to one, the corresponding private key has signed the child zone's - apex DNSKEY RRset, and the resulting RRSIG RR authenticates the - child zone's apex DNSKEY RRset. - - If the referral from the parent zone did not contain a DS RRset, the - response should have included a signed NSEC RRset proving that no DS - RRset exists for the delegated name (see Section 3.1.4). A - security-aware resolver MUST query the name servers for the parent - zone for the DS RRset if the referral includes neither a DS RRset nor - a NSEC RRset proving that the DS RRset does not exist (see Section - 4). - - If the resolver authenticates an NSEC RRset that proves that no DS - RRset is present for this zone, then there is no authentication path - leading from the parent to the child. If the resolver has an initial - DNSKEY or DS RR that belongs to the child zone or to any delegation - below the child zone, this initial DNSKEY or DS RR MAY be used to - re-establish an authentication path. If no such initial DNSKEY or DS - RR exists, the resolver can not authenticate RRsets in or below the - child zone. - - Note that, for a signed delegation, there are two NSEC RRs associated - with the delegated name. One NSEC RR resides in the parent zone, and - can be used to prove whether a DS RRset exists for the delegated - name. The second NSEC RR resides in the child zone, and identifies - which RRsets are present at the apex of the child zone. The parent - NSEC RR and child NSEC RR can always be distinguished, since the SOA - bit will be set in the child NSEC RR and clear in the parent NSEC RR. - A security-aware resolver MUST use the parent NSEC RR when attempting - to prove that a DS RRset does not exist. - - If the resolver does not support any of the algorithms listed in an - authenticated DS RRset, then the resolver will not be able to verify - the authentication path to the child zone. In this case, the - resolver SHOULD treat the child zone as if it were unsigned. - -5.3 Authenticating an RRset Using an RRSIG RR - - A resolver can use an RRSIG RR and its corresponding DNSKEY RR to - attempt to authenticate RRsets. The resolver first checks the RRSIG - RR to verify that it covers the RRset, has a valid time interval, and - identifies a valid DNSKEY RR. The resolver then constructs the - - - -Arends, et al. Expires August 16, 2004 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - canonical form of the signed data by appending the RRSIG RDATA - (excluding the Signature Field) with the canonical form of the - covered RRset. Finally, resolver uses the public key and signature - to authenticate the signed data. Section 5.3.1, Section 5.3.2, and - Section 5.3.3 describe each step in detail. - -5.3.1 Checking the RRSIG RR Validity - - A security-aware resolver can use an RRSIG RR to authenticate an - RRset if all of the following conditions hold: - - o The RRSIG RR and the RRset MUST have the same owner name and the - same class; - - o The RRSIG RR's Signer's Name field MUST be the name of the zone - that contains the RRset; - - o The RRSIG RR's Type Covered field MUST equal the RRset's type; - - o The number of labels in the RRset owner name MUST be greater than - or equal to the value in the RRSIG RR's Labels field; - - o The resolver's notion of the current time MUST be less than or - equal to the time listed in the RRSIG RR's Expiration field; - - o The resolver's notion of the current time MUST be greater than or - equal to the time listed in the RRSIG RR's Inception field; - - o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST - match the owner name, algorithm, and key tag for some DNSKEY RR in - the zone's apex DNSKEY RRset; - - o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY - RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) - set to one. - - It is possible for more than one DNSKEY RR to match the conditions - above. In this case, the resolver can not predetermine which DNSKEY - RR to use to authenticate the signature, MUST try each matching - DNSKEY RR until the resolver has either validated the signature or - has run out of matching public keys to try. - - Note that this authentication process is only meaningful if the - resolver authenticates the DNSKEY RR before using it to validate - signatures. The matching DNSKEY RR is considered to be authentic if: - - o The apex DNSKEY RRset containing the DNSKEY RR is considered - authentic; or - - - -Arends, et al. Expires August 16, 2004 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - o The RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, - and the DNSKEY RR either matches an authenticated DS RR from the - parent zone or matches a DS RR or DNSKEY RR that the resolver has - been preconfigured to believe to be authentic. - - -5.3.2 Reconstructing the Signed Data - - Once the RRSIG RR has met the validity requirements described in - Section 5.3.1, the resolver needs to reconstruct the original signed - data. The original signed data includes RRSIG RDATA (excluding the - Signature field) and the canonical form of the RRset. Aside from - being ordered, the canonical form of the RRset might also differ from - the received RRset due to DNS name compression, decremented TTLs, or - wildcard expansion. The resolver should use the following to - reconstruct the original signed data: - - signed_data = RRSIG_RDATA | RR(1) | RR(2)... where - - "|" denotes concatenation - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signature field excluded and the Signer's Name - in canonical form. - - RR(i) = name | class | type | OrigTTL | RDATA length | RDATA - - name is calculated according to the function below - - class is the RRset's class - - type is the RRset type and all RRs in the class - - OrigTTL is the value from the RRSIG Original TTL field - - All names in the RDATA field are in canonical form - - The set of all RR(i) is sorted into canonical order. - - To calculate the name: - let rrsig_labels = the value of the RRSIG Labels field - - let fqdn = RRset's fully qualified domain name in - canonical form - - let fqdn_labels = Label count of the fqdn above. - - if rrsig_labels = fqdn_labels, - - - -Arends, et al. Expires August 16, 2004 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - name = fqdn - - if rrsig_labels < fqdn_labels, - name = "*." | the rightmost rrsig_label labels of the - fqdn - - if rrsig_labels > fqdn_labels - the RRSIG RR did not pass the necessary validation - checks and MUST NOT be used to authenticate this - RRset. - - The canonical forms for names and RRsets are defined in - [I-D.ietf-dnsext-dnssec-records]. - - NSEC RRsets at a delegation boundary require special processing. - There are two distinct NSEC RRsets associated with a signed delegated - name. One NSEC RRset resides in the parent zone, and specifies which - RRset are present at the parent zone. The second NSEC RRset resides - at the child zone, and identifies which RRsets are present at the - apex in the child zone. The parent NSEC RRset and child NSEC RRset - can always be distinguished since only the child NSEC RRs will - specify an SOA RRset exists at the name. When reconstructing the - original NSEC RRset for the delegation from the parent zone, the NSEC - RRs MUST NOT be combined with NSEC RRs from the child zone, and when - reconstructing the original NSEC RRset for the apex of the child - zone, the NSEC RRs MUST NOT be combined with NSEC RRs from the parent - zone. - - Note also that each of the two NSEC RRsets at a delegation point has - a corresponding RRSIG RR with an owner name matching the delegated - name, and each of these RRSIG RRs is authoritative data associated - with the same zone that contains the corresponding NSEC RRset. If - necessary, a resolver can tell these RRSIG RRs apart by checking the - Signer's Name field. - -5.3.3 Checking the Signature - - Once the resolver has validated the RRSIG RR as described in Section - 5.3.1 and reconstructed the original signed data as described in - Section 5.3.2, the resolver can attempt to use the cryptographic - signature to authenticate the signed data, and thus (finally!) - authenticate the RRset. - - The Algorithm field in the RRSIG RR identifies the cryptographic - algorithm used to generate the signature. The signature itself is - contained in the Signature field of the RRSIG RDATA, and the public - key used to verify the signature is contained in the Public Key field - of the matching DNSKEY RR(s) (found in Section 5.3.1). - - - -Arends, et al. Expires August 16, 2004 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - [I-D.ietf-dnsext-dnssec-records] provides a list of algorithm types, - and provides pointers to the documents that define each algorithm's - use. - - Note that it is possible for more than one DNSKEY RR to match the - conditions in Section 5.3.1. In this case, the resolver can only - determine which DNSKEY RR by trying each matching public key until - the resolver either succeeds in validating the signature or runs out - of keys to try. - - If the Labels field of the RRSIG RR is not equal to the number of - labels in the RRset's fully qualified owner name, then the RRset is - either invalid or the result of wildcard expansion. The resolver - MUST verify that wildcard expansion was applied properly before - considering the RRset to be authentic. Section 5.3.4 describes how - to determine whether a wildcard was applied properly. - - If other RRSIG RRs also cover this RRset, the local resolver security - policy determines whether the resolver also needs to test these RRSIG - RRs, and determines how to resolve conflicts if these RRSIG RRs lead - to differing results. - - If the resolver accepts the RRset as authentic, the resolver MUST set - the TTL of the RRSIG RR and each RR in the authenticated RRset to a - value no greater than the minimum of: - - o The RRset's TTL as received in the response; - - o The RRSIG RR's TTL as received in the response; and - - o The value in the RRSIG RR's Original TTL field. - - -5.3.4 Authenticating A Wildcard Expanded RRset Positive Response - - If the number of labels in an RRset's owner name is greater than the - Labels field of the covering RRSIG RR, then the RRset and its - covering RRSIG RR were created as a result of wildcard expansion. - Once the resolver has verified the signature as described in Section - 5.3, the resolver must take additional steps to verify the - non-existence of an exact match or closer wildcard match for the - query. Section 5.4 discusses these steps. - - Note that the response received by the resolver should include all - NSEC RRs needed to authenticate the response (see Section 3.1.3). - -5.4 Authenticated Denial of Existence - - - - -Arends, et al. Expires August 16, 2004 [Page 32] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - A resolver can use authenticated NSEC RRs to prove that an RRset is - not present in a signed zone. Security-aware name servers should - automatically include any necessary NSEC RRs for signed zones in - their responses to security-aware resolvers. - - Security-aware resolvers MUST first authenticate NSEC RRsets - according to the standard RRset authentication rules described in - Section 5.3, then apply the NSEC RRsets as follows: - - o If the requested RR name matches the owner name of an - authenticated NSEC RR, then the NSEC RR's type bit map field lists - all RR types present at that owner name, and a resolver can prove - that the requested RR type does not exist by checking for the RR - type in the bit map. If the number of labels in an authenticated - NSEC RR's owner name equals the Labels field of the covering RRSIG - RR, then the existence of the NSEC RR proves that wildcard - expansion could not have been used to match the request. - - o If the requested RR name would appear after an authenticated NSEC - RR's owner name and before the name listed in that NSEC RR's Next - Domain Name field according to the canonical DNS name order - defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with - the requested name exist in the zone. However, it is possible - that a wildcard could be used to match the requested RR owner name - and type, so proving that the requested RRset does not exist also - requires proving that no possible wildcard RRset exists that could - have been used to generate a positive response. - - To prove non-existence of an RRset, the resolver must be able to - verify both that the queried RRset does not exist and that no - relevant wildcard RRset exists. Proving this may require more than - one NSEC RRset from the zone. If the complete set of necessary NSEC - RRsets is not present in a response (perhaps due to message - truncation), then a security-aware resolver MUST resend the query in - order to attempt to obtain the full collection of NSEC RRs necessary - to verify non-existence of the requested RRset. As with all DNS - operations, however, the resolver MUST bound the work it puts into - answering any particular query. - - Since a verified NSEC RR proves the existence of both itself and its - corresponding RRSIG RR, a verifier MUST ignore the settings of the - NSEC and RRSIG bits in an NSEC RR. - -5.5 Authentication Example - - Appendix C shows an example the authentication process. - - - - - -Arends, et al. Expires August 16, 2004 [Page 33] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -6. IANA Considerations - - [I-D.ietf-dnsext-dnssec-records] contains a review of the IANA - considerations introduced by DNSSEC. The additional IANA - considerations discussed in this document: - - [RFC2535] reserved the CD and AD bits in the message header. The - meaning of the AD bit was redefined in [RFC3655] and the meaning of - both the CD and AD bit are restated in this document. No new bits in - the DNS message header are defined in this document. - - [RFC2671] introduced EDNS and [RFC3225] reserved the DNSSEC OK bit - and defined its use. The use is restated but not altered in this - document. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 34] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -7. Security Considerations - - This document describes how the DNS security extensions use public - key cryptography to sign and authenticate DNS resource record sets. - Please see [I-D.ietf-dnsext-dnssec-intro] for terminology and general - security considerations related to DNSSEC; see - [I-D.ietf-dnsext-dnssec-intro] for considerations specific to the - DNSSEC resource record types. - - An active attacker who can set the CD bit in a DNS query message or - the AD bit in a DNS response message can use these bits to defeat the - protection which DNSSEC attempts to provide to security-oblivious - recursive-mode resolvers. For this reason, use of these control bits - by a security-aware recursive-mode resolver requires a secure - channel. See Section 3.2.2 and Section 4.8 for further discussion. - - The protocol described in this document attempts to extend the - benefits of DNSSEC to security-oblivious stub resolvers. However, - since recovery from validation failures is likely to be specific to - particular applications, the facilities that DNSSEC provides for stub - resolvers may prove inadequate. Operators of security-aware - recursive name servers will need to pay close attention to the - behavior of the applications which use their services when choosing a - local validation policy; failure to do so could easily result in the - recursive name server accidently denying service to the clients it is - intended to support. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 35] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -8. Acknowledgements - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 36] - -Internet-Draft DNSSEC Protocol Modifications 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. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [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. - - [I-D.ietf-dnsext-dnssec-intro] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-09 (work in progress), - February 2004. - - [I-D.ietf-dnsext-dnssec-records] - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "Resource Records for DNS Security Extensions", - draft-ietf-dnsext-dnssec-records-07 (work in progress), - February 2004. - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 37] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Informative References - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS - Authenticated Data (AD) bit", RFC 3655, November 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [I-D.ietf-dnsext-wcard-clarify] - Halley, B. and E. Lewis, "Clarifying the Role of Wild Card - Domains in the Domain Name System", - draft-ietf-dnsext-wcard-clarify-02 (work in progress), - September 2003. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - Matt Larson - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166-6503 - USA - - EMail: mlarson@verisign.com - - - - - - -Arends, et al. Expires August 16, 2004 [Page 38] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - Rob Austein - Internet Systems Consortium - 950 Charter Street - Redwood City, CA 94063 - USA - - EMail: sra@isc.org - - - Dan Massey - USC Information Sciences Institute - 3811 N. Fairfax Drive - Arlington, VA 22203 - USA - - EMail: masseyd@isi.edu - - - Scott Rose - National Institute for Standards and Technology - 100 Bureau Drive - Gaithersburg, MD 20899-8920 - USA - - EMail: scott.rose@nist.gov - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 39] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Appendix A. Signed Zone Example - - The following example shows a (small) complete signed zone. - - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - 3600 NS ns1.example. - 3600 NS ns2.example. - 3600 RRSIG NS 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz - +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj - s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY - eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH - FTVyQbVkcaxQ6U2FbZtMbfo//go= ) - 3600 MX 1 xx.example. - 3600 RRSIG MX 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - JE9Kcx4NaXpaO2Jjyo5yi+DT6wgxwregHg18 - 7xOOF0KjIYQpaoFY3Kp8MAKT7aupZpr5DmHe - IpBNI6jC59A2uNVP+6UfqAyJMoNnq9d/paM+ - M+adwb+xrT+dZYpFZzyeXPmBqA/PVAtw1d5Q - 7wxkDWyzgasGiMNIKgYrm9vXz04= ) - 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - 3600 RRSIG NSEC 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT - vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX - TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g - Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 - 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) - 3600 DNSKEY 256 3 5 ( - AQPmfvH5TF0S/vnd08C9EbVlG/+wbmFecyjH - UtEh3d8h045BE36XSbr0XZU6kPLgA/Shf7TV - fKduDMH7ASlP8MpUX4ci9ZiXffBjUKvsHORv - BgtAcUYRofvzRZ/jl078bI/JJg9ee4ndY6FO - - - -Arends, et al. Expires August 16, 2004 [Page 40] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - 5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q== - ) - 3600 DNSKEY 257 3 5 ( - AQOwHAYrbYVzzKHF0PDHSt4zY+Vz1+yLz1/U - Pv2j2nukkWKLipnqg8X2vI754SRpqwpPCKpv - klUr36CE0byYLOpRE5WlKZjXm3uzDFIVdHUE - 2lFwkMP9tSHUrXbjypiZWZP71qNuBeYCDAyT - nLu7mxrT1Y7GdSV7I6vwt0mDSWQDXQ== - ) - 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - Pkxt/YJHVcnm3+56YGYziM69NDFJDEernUEU - pU1yBY8H7TlvIWhJz/qHsWcPt79ri0lP0Ho5 - YDVp6GOFxBcR/7ejtV/izHO5tb88WM8xJLNc - tJZeSSVG62kt1q5fiKKsxhhpqZFQgc+h6htG - PjJstq6fvRq8kX7TPJcljUmDFKM= ) - 3600 RRSIG DNSKEY 5 1 3600 20040115201552 ( - 20031216201552 60717 example. - EVJnkWJSUTdaxIRX374Ki84OhYRYB+7TM/Z/ - C8ufeGjcZkAPpkA3XjPao+4kG/lR/qW8oyNK - L0g5BI9fkcptXjf+0y3n5y/con6f+FOwHgdY - J7/fjSW27L3Je0MSrR3T/RNaokZafWDCT/34 - Uu/YHFJKdBxs7sMeSBJ4UPm2uwc= ) - a.example. 3600 IN NS ns1.a.example. - 3600 IN NS ns2.a.example. - 3600 DS 48327 5 1 ( - DFEB5E00E71A4DED5CABBBD7F15F24871983 - CAB7 ) - 3600 RRSIG DS 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ - hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb - rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c - ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC - 0yfe2uolEkeegjesDZuF+fC61Eg= ) - 3600 NSEC ai.example. NS DS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - iq8exEVhvdx4s3w3VmK3Mzfngwpmpv3NwOpb - RMtgba/u5kyD4Mf03jyLtJLUevry2rZcRjF1 - 3kDuKmewJ0jWA4sMuljJpx10rhvwlcKaJE3O - ViEb66GFqDxCXExikKWsPm8qckYZLQ7ABNjf - YgfAHJEJJj7K88QbKEK4/Je1hyk= ) - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - ai.example. 3600 IN A 192.0.2.9 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - - - -Arends, et al. Expires August 16, 2004 [Page 41] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 - jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c - Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk - OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A - sWifTxvcG5hv+A6TOd0O2xJYRik= ) - 3600 HINFO "KLH-10" "ITS" - 3600 RRSIG HINFO 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - 4aSnKLykRT7htnnS8HtlM0YLMwU1Z92pvf/C - hxETE5B6W8x+uJs9KV9nlZ/B6TNk4nFRgKg2 - KpKvEq7xUybNKwbbeGZE9n2fDH0FeDgHjqW2 - Ke0lQuszRxjx+McTEqVJMyHrBKnqNdUh1G92 - xo9NLoltg0GuwggZM240pRoTwO8= ) - 3600 AAAA 2001:db8::f00:baa9 - 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 - 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ - G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI - A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI - zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) - 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - Xr3qBss/U0yN12SL2stWs0AACeQjvRms9+xE - ishTjb4B/XQ8yAfAmby5yF5DKR8900M0hT3Y - ikp/wIF4TmtH5W7UFN13To/GWGJygaa7wyzU - 4AtgtRwmmevSAgzxhC7yRXUWyhpfQoW7zwpR - ovChG5Ih3TOa8Qnch4IJQVfSFNU= ) - b.example. 3600 IN NS ns1.b.example. - 3600 IN NS ns2.b.example. - 3600 NSEC ns1.example. NS RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs - VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW - VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN - k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX - GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - ns1.example. 3600 IN A 192.0.2.1 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 - CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs - RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf - +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa - - - -Arends, et al. Expires August 16, 2004 [Page 42] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) - 3600 NSEC ns2.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ - sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 - eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA - s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj - I2A5W86mMEbSgEF/pZHX/wi5FJI= ) - ns2.example. 3600 IN A 192.0.2.2 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL - xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK - HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht - sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG - wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) - 3600 NSEC *.w.example. A RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - Vxovi9gQjxqYBI5QF2ZcbZ/5my7C+22uXKVb - IN5dmV82uu2TqJ4g2a2KKywlVi+4Kcnm4O3b - f7pV4g7pcQopa9AFiY8byFrPftuNvraDyp6J - aPllr/HnIPGP4Vw78LKW4n812K2VxV8p/IJl - yCup5bk/Dr47eU2/6+lqrBTOV8Q= ) - *.w.example. 3600 IN MX 1 ai.example. - 3600 RRSIG MX 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg - OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns - Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA - n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK - 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) - 3600 NSEC x.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr - f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 - 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK - /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW - ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) - x.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 3 3600 20040115201552 ( - 20031216201552 41681 example. - g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW - ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m - 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY - MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv - - - -Arends, et al. Expires August 16, 2004 [Page 43] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - btznHMFDIbtuw/tAX7xXH2pDDHY= ) - 3600 NSEC x.y.w.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 3 3600 20040115201552 ( - 20031216201552 41681 example. - zwAU3bQHLeDawvqbvlmNosGMGDz9wdEe/iia - CU8DbanqOzUiPfqEgBN3evFMpGBM9H3zMjGA - EjnP4fMerk7dzD8jfyLzNdCGsJjPtnEgctGA - aNd+NGtSmedzeNGvlj7mNxnAdqHFY1c902pT - 3lMXiX4KNWUhB87q/pT/5z+xrqY= ) - x.y.w.example. 3600 IN MX 1 xx.example. - 3600 RRSIG MX 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - slLY7KbPseET3XMJz/yGJBJpDczy1N2W4SAD - v5Jx/osOWviEJBpUEwRndX+VmsmQJqKsQxtE - unmxl4Sh9cuVyALJy1ByF9hZ0+E3i35qoxOK - Oe+JZyiEiebZfZ8doH5J+keCkIQ8EHzw8Hnk - Iykd5UmaTO5j4LlRnAvF8Z1m9/k= ) - 3600 NSEC xx.example. MX RRSIG NSEC - 3600 RRSIG NSEC 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 - VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj - Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq - AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J - viOQHZ6I4xoZQP5G7r98/PhlrLM= ) - xx.example. 3600 IN A 192.0.2.10 - 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap - tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq - iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS - KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G - 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) - 3600 HINFO "KLH-10" "TOPS-20" - 3600 RRSIG HINFO 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - fZIotOyJqpRTZ0KH5lsZIksuyslAMckBclZw - p3LJiaYAibf+rwNFpS3CPUFsyCrA8UL+iVfA - gTxa6O8+yKYsDXZ2x6wPPDqmBEeHT1XiKEA/ - pC+O35tVS6oLMYWJyGAGBJitXZQGr+MiBvSp - EDXT07qFXtGntvBSpF9uQbEub6Y= ) - 3600 AAAA 2001:db8::f00:baaa - 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 - dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD - mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg - CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z - - - -Arends, et al. Expires August 16, 2004 [Page 44] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - D4ZubIon0XGe9fIjLnmb3pX/FUk= ) - 3600 NSEC example. A HINFO AAAA RRSIG NSEC - 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - sbF8bfC6zqyuio2iov0C9byDCejWvxMJYgjn - uy3nXbvVXXzcA+d2zG6uPQ8VLRSolCE+OQqE - NsABxmoBhBwdxCrCpnU8SvzAkrRLwuOqAu1a - 1yBIfd352PHkQg1sxVDHGoFo3cFKzvkuD187 - sSNF3PAC0HPadh7SdHmXlFQtQ44= ) - - The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA - Flags indicate that each of these DNSKEY RRs is a zone key. One of - these DNSKEY RRs also has the SEP flag set and has been used to sign - the apex DNSKEY RRset; this is the key which should be hashed to - generate a DS record to be inserted into the parent zone. The other - DNSKEY is used to sign all the other RRsets in the zone. - - The zone includes a wildcard entry "*.w.example". Note that the name - "*.w.example" is used in constructing NSEC chains, and that the RRSIG - covering the "*.w.example" MX RRset has a label count of 2. - - The zone also includes two delegations. The delegation to - "b.example" includes an NS RRset, glue address records, and an NSEC - RR; note that only the NSEC RRset is signed. The delegation to - "a.example" provides a DS RR; note that only the NSEC and DS RRsets - are signed. - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 45] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Appendix B. Example Responses - - The examples in this section show response messages using the signed - zone example in Appendix A. - -B.1 Answer - - A successful query to an authoritative server. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - x.w.example. IN MX - - ;; Answer - x.w.example. 3600 IN MX 1 xx.example. - x.w.example. 3600 RRSIG MX 5 3 3600 20040115201552 ( - 20031216201552 41681 example. - g2H7+tChKsYRqxDkrLZgraaKBF2pah6YNCEW - ORmXLzrB6RWtXbjVHXjagBhZYsMPzkPqwn4m - 8IYSaPD0X3z001aXsgsh9WF+AOgbqa0eoIIY - MHIEJ9MHB5cS33XXv2fY6iFmjLuZUz+pNSfv - btznHMFDIbtuw/tAX7xXH2pDDHY= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz - +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj - s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY - eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH - FTVyQbVkcaxQ6U2FbZtMbfo//go= ) - - ;; Additional - xx.example. 3600 IN A 192.0.2.10 - xx.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - fQfj8RhKKhC2vI0OJxgnZLeXFhpMmpjwV/ap - tCkUP1YagLF9gB4NLRUrV1QO/e1f2zyxSngq - iDW9yUJjKQcv9EWzbDd0kzXxPu11y/iS7oMS - KOsVB4Mp7BM5q2kcBXBrM+Rr0eibvBXmHs8G - 0ToQVY81bPc3WXKZjRxQl3jiKtU= ) - xx.example. 3600 AAAA 2001:db8::f00:baaa - xx.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - kLh5dTA0XBIIjEV/guGo9pEOKNZ0Elvbuhm2 - - - -Arends, et al. Expires August 16, 2004 [Page 46] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD - mDhMUKFMhsVqCMwqfYjxXvTOG21BKyCki0Gg - CgvRD47lC4NnCSaB6B6Ysj0Aupv75Nnqwi9Z - D4ZubIon0XGe9fIjLnmb3pX/FUk= ) - ns1.example. 3600 IN A 192.0.2.1 - ns1.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - 5FrF88yOT6iiBdkiQLqaXkma0gCQza5/kLK7 - CgoMNlCR2QYhsur2X7Fex2/OYEmOkzOqO7Gs - RoIc4e3nt+kfpd/4Htp9T5v+NXmMVPmW3Jmf - +ZGpEf86AI7Rw3x2bSmVOzsxa4xUxE+DuINa - WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) - ns2.example. 3600 IN A 192.0.2.2 - ns2.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - sfFOjxKZz1LMhyDfmB43RhIUVOHlVbLtP0lL - xBsxcHt48NKLth81pzSWRFQfUtMCjaGWMtuK - HFEVaAQXcwllWXXLbVpc9a32govT+hsapcht - sPyxkcEpYEFTtB93edKRVQ0IgZBPOI02R6vG - wCbeY0Rl8MIRcAaiIkFos/8hd1g= ) - - -B.2 Name Error - - An authoritative name error. The NSEC RRs prove that the name does - not exist and that no covering wildcard exists. - - ;; Header: QR AA DO RCODE=3 - ;; - ;; Question - ml.example. IN A - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - - - -Arends, et al. Expires August 16, 2004 [Page 47] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs - VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW - VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN - k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX - GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT - vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX - TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g - Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 - 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) - - ;; Additional - ;; (empty) - - -B.3 No Data Error - - A "NODATA" response. The NSEC RR proves that the name exists and - that the requested RR type does not. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - ns1.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - - - -Arends, et al. Expires August 16, 2004 [Page 48] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC - ns1.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - WaeyPcQtFjXj4cxDcqVseuhZPA4K/qSb7ylZ - sj55rJ8OqEKDYt71e1MT3F5p76wKtLaPmoc0 - eLGnDD+Xouu/tWXtsjj5QpMhl13DUD0GLBiA - s/wwxreW0SWkh4JJirodDE7vSIiI6gPJYhIj - I2A5W86mMEbSgEF/pZHX/wi5FJI= ) - - ;; Additional - ;; (empty) - - -B.4 Referral to Signed Zone - - Referral to a signed zone. The DS RR contains the data which the - resolver will need to validate the corresponding DNSKEY RR in the - child zone's apex. - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.a.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - a.example. 3600 IN NS ns1.a.example. - a.example. 3600 IN NS ns2.a.example. - a.example. 3600 DS 48327 5 1 ( - DFEB5E00E71A4DED5CABBBD7F15F24871983 - CAB7 ) - a.example. 3600 RRSIG DS 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - wj4ME4MuuZN77PGiE8xgBmCXpRpUocRJLbW/ - hBbMGk2qtA9ose1Jr2F9rOU6zvU9Z0HQgxnb - rSBfaeCZFmk3yOlo9Uqref4ukk9hwIjzxo7c - ZbJstCYWiLF57i1k5Cj6npMbUZSIgRGcB+dC - 0yfe2uolEkeegjesDZuF+fC61Eg= ) - - ;; Additional - ns1.a.example. 3600 IN A 192.0.2.5 - ns2.a.example. 3600 IN A 192.0.2.6 - - - - -Arends, et al. Expires August 16, 2004 [Page 49] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -B.5 Referral to Unsigned Zone - - Referral to an unsigned zone. The NSEC RR proves that no DS RR for - this delegation exists in the parent zone. - - ;; Header: QR DO RCODE=0 - ;; - ;; Question - mc.b.example. IN MX - - ;; Answer - ;; (empty) - - ;; Authority - b.example. 3600 IN NS ns1.b.example. - b.example. 3600 IN NS ns2.b.example. - b.example. 3600 NSEC ns1.example. NS RRSIG NSEC - b.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - nFufQRM2UtSYTAwQaKEnIpua5ZHLqJrcLGAs - VUpLoPOEsAXex1N3uIJQWmoXnr9Up00G7jbW - VOVaLUvXR7b/4sQkyQLbOl9GpWiA1NYjPneN - k3i+OWi3NmvRN71CuNky87DrVg0p2Mf2MjLX - GRIZP9W1bgeDHZRcCNz2hQ67SgY= ) - - ;; Additional - ns1.b.example. 3600 IN A 192.0.2.7 - ns2.b.example. 3600 IN A 192.0.2.8 - - -B.6 Wildcard Expansion - - A successful query which was answered via wildcard expansion. The - label count in the answer's RRSIG RR indicates that a wildcard RRset - was expanded to produce this response, and the NSEC RR proves that no - closer match exists in the zone. - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN MX - - ;; Answer - a.z.w.example. 3600 IN MX 1 ai.example. - a.z.w.example. 3600 RRSIG MX 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - mzcZPkLFaFycrnJuHY8LHdmvmyD8prPbQXHg - OXuGLRpO+qRU04v97KYNy8si1Ijmo85nI4Ns - - - -Arends, et al. Expires August 16, 2004 [Page 50] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA - n7NlR05Rf2tE3e54a1LP0po55yqGtxdPKWOK - 91Ena87PA2MvoOE+A3ZpEk8MjEE= ) - - ;; Authority - example. 3600 NS ns1.example. - example. 3600 NS ns2.example. - example. 3600 RRSIG NS 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - YgTFj4yXRzbOddwfOTQhLHGPWm7x55ZRoPVz - +bxuPHTozw3I2gpno81Em1RuVekWJHivAvQj - s1h72oh+ipBadjCGSRu46u1T9JYUSLxLecgY - eEw9qDeQIoZHRny5bYrX1x87ItEo5+n1lwOH - FTVyQbVkcaxQ6U2FbZtMbfo//go= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 - VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj - Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq - AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J - viOQHZ6I4xoZQP5G7r98/PhlrLM= ) - - ;; Additional - ai.example. 3600 IN A 192.0.2.9 - ai.example. 3600 RRSIG A 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 - jiteGyki6CAEJKm1Dr2bjlrzdgfFBrpIac9c - Up4zMlAkitX/7D9vFus8nLSvEHngpdc12Hlk - OrvT0EsYA2XeQ0h3PPQk5FcK2ekxZvw5Zm7A - sWifTxvcG5hv+A6TOd0O2xJYRik= ) - ai.example. 3600 AAAA 2001:db8::f00:baa9 - ai.example. 3600 RRSIG AAAA 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - oq16/pU4MuvkgQyFqGrHqggz47i6iZL714u5 - 9UsmGM1Y/qyQZsR4wi6hC2zIWXNJxIPIhitJ - G6M5pjExUH/vOe0DIW73t/NHzcj0zOjxAPEI - A+jBlOwn2EY5q87PMzBIeHWSx7DxtEIMC8XI - zkK+1+Z5aqj1pmZ4yXUvd2znGnQ= ) - - -B.7 Wildcard No Data Error - - A "NODATA" response for a name covered by a wildcard. The NSEC RRs - prove that the matching wildcard name does not have any RRs of the - requested type and that no closer match exists in the zone. - - - - -Arends, et al. Expires August 16, 2004 [Page 51] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - a.z.w.example. IN AAAA - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC - x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040115201552 ( - 20031216201552 41681 example. - sjHnEm4kiIK64bRskNc3vxEHe12l9Lg8Y7G8 - VsXMUEEDeBCB3qlrGQeqhdl+gsQGRBiOA8Jj - Jr5F9RNZepVLGv+t5fALeoe0gLHsWoTlfTdq - AJ8a2E5BZYYvy9hjh9Y4Kqd23HOv21o2OC0J - viOQHZ6I4xoZQP5G7r98/PhlrLM= ) - *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC - *.w.example. 3600 RRSIG NSEC 5 2 3600 20040115201552 ( - 20031216201552 41681 example. - OeBMvLlBam90xU/KxvyAYBNGWpvMf1TbaJFr - f0Ip+tTkiqeEE8fx2ZAg1JcY9uhldms/9y45 - 9HxO9Q3ZO6jfQzsx62YQaBte85d/Udhzf4AK - /RHsZGSOabsu6DhacWC2Ew7vEgcMfiPHFzWW - ANi1i3zhPOd3+Vjt4IQzaJXqVZE= ) - - ;; Additional - ;; (empty) - - -B.8 DS Child Zone No Data Error - - A "NODATA" response for a QTYPE=DS query which was mistakenly sent to - a name server for the child zone. - - - -Arends, et al. Expires August 16, 2004 [Page 52] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - ;; Header: QR AA DO RCODE=0 - ;; - ;; Question - example. IN DS - - ;; Answer - ;; (empty) - - ;; Authority - example. 3600 IN SOA ns1.example. bugs.x.w.example. ( - 1071609350 - 3600 - 300 - 3600000 - 3600 - ) - example. 3600 RRSIG SOA 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - F1KxMLu2zwDUFgUtdAqCq6F9zkaIPb3B7dzA - hRLp8riOMQQgCCQ4x9KvSu2xLJa539jQIRW0 - VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj - CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM - owLe/OV+Qqqic7ShV/S9l2YJF9I= ) - example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY - example. 3600 RRSIG NSEC 5 1 3600 20040115201552 ( - 20031216201552 41681 example. - kE9ARiewdQSCsLXY9ldasZEW54kKhfEN2lsT - vDD4biJsTPeaOXJ6bJ7s0CvybknENin3uqIX - TAy6bsL919sEI3/SoHiRCwHalVmUPIWCsz4g - Ee7gkQ+1uFzi7L8LGX9NjQI74s3M//OW2+T4 - 7T/nOEOVZujD8IN/Utv+KUg+P6U= ) - - ;; Additional - ;; (empty) - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 53] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - -Appendix C. Authentication Examples - - The examples in this section show how the response messages in - Appendix B are authenticated. - -C.1 Authenticating An Answer - - The query in section Appendix B.1 returned an MX RRset for - "x.w.example.com". The corresponding RRSIG indicates the MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 41681. - The resolver needs the corresponding DNSKEY RR in order to - authenticate this answer. The discussion below describes how a - resolver might obtain this DNSKEY RR. - - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 3 indicates the answer was - not the result of wildcard expansion. The "x.w.example.com" MX RRset - is placed in canonical form and, assuming the current time falls - between the signature inception and expiration dates, the signature - is authenticated. - -C.1.1 Authenticating the example DNSKEY RR - - This example shows the logical authentication process that starts - from the a preconfigured root DNSKEY (or DS RR) and moves down the - tree to authenticate the desired "example" DNSKEY RR. Note the - logical order is presented for clarity and an implementation may - choose to construct the authentication as referrals are received or - may choose to construct the authentication chain only after all - RRsets have been obtained, or in any other combination it sees fit. - The example here demonstrates only the logical process and does not - dictate any implementation rules. - - We assume the resolver starts with an preconfigured DNSKEY RR for the - root zone (or a preconfigured DS RR for the root zone). The resolver - checks this preconfigured DNSKEY RR is present in the root DNSKEY - RRset (or the DS RR matches some DNSKEY in the root DNSKEY RRset), - this DNSKEY RR has signed the root DNSKEY RRset and the signature - lifetime is valid. If all these conditions are met, all keys in the - DNSKEY RRset are considered authenticated. The resolver then uses - one (or more) of the root DNSKEY RRs to authenticate the "example" DS - RRset. Note the resolver may need to query the root zone to obtain - the root DNSKEY RRset and/or "example" DS RRset. - - Once the DS RRset has been authenticated using the root DNSKEY, the - resolver checks the "example" DNSKEY RRset for some "example" DNSKEY - RR that matches one of the authenticated "example" DS RRs. If such a - - - -Arends, et al. Expires August 16, 2004 [Page 54] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - matching "example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the "example" - DNSKEY RRset are considered authenticated. - - Finally the resolver checks that some DNSKEY RR in the "example" - DNSKEY RRset uses algorithm 5 and has a key tag of 41681. This - DNSKEY is used to authenticated the RRSIG included in the response. - If multiple "example" DNSKEY RRs have algorithm 5 and key tag of - 41681, then each DNSKEY RR is tried and the answer is authenticated - if either DNSKEY RR validates the signature as described above. - -C.2 Name Error - - The query in section Appendix B.2 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. The NSEC RRs are - authenticated in a manner identical to that of the MX RRset discussed - above. - -C.3 No Data Error - - The query in section Appendix B.3 returned an NSEC RR that proves the - requested name exists, but the requested RR type does not exist. The - negative reply is authenticated by verifying the NSEC RR. The NSEC - RR is authenticated in a manner identical to that of the MX RRset - discussed above. - -C.4 Referral to Signed Zone - - The query in section Appendix B.4 returned a referral to the signed - "a.example." zone. The DS RR is authenticated in a manner identical - to that of the MX RRset discussed above. This DS RR is used to - authenticate the "a.example" DNSKEY RRset. - - Once the "a.example" DS RRset has been authenticated using the - "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset - for some "a.example" DNSKEY RR that matches the DS RR. If such a - matching "a.example" DNSKEY is found, the resolver checks this DNSKEY - RR has signed the "a.example" DNSKEY RRset and the signature lifetime - is valid. If all these conditions are met, all keys in the - "a.example" DNSKEY RRset are considered authenticated. - -C.5 Referral to Unsigned Zone - - The query in section Appendix B.5 returned a referral to an unsigned - "b.example." zone. The NSEC proves that no authentication leads from - "example" to "b.example" and the NSEC RR is authenticated in a manner - - - -Arends, et al. Expires August 16, 2004 [Page 55] - -Internet-Draft DNSSEC Protocol Modifications February 2004 - - - identical to that of the MX RRset discussed above. - -C.6 Wildcard Expansion - - The query in section Appendix B.6 returned an answer that was - produced as a result of wildcard expansion. The RRset expanded as - the similar to The corresponding RRSIG indicates the MX RRset was - signed by an "example" DNSKEY with algorithm 5 and key tag 41681. - The RRSIG indicates the original TTL of the MX RRset was 3600 and, - for the purpose of authentication, the current TTL is replaced by - 3600. The RRSIG labels field value of 2 indicates the answer the - result of wildcard expansion since the "a.z.w.example" name contains - 4 labels. The name "a.z.w.w.example" is replaced by "*.w.example", - the MX RRset is placed in canonical form and, assuming the current - time falls between the signature inception and expiration dates, the - signature is authenticated. - - The NSEC proves that no closer match (exact or closer wildcard) could - have been used to answer this query and the NSEC RR must also be - authenticated before the answer is considered valid. - -C.7 Wildcard No Data Error - - The query in section Appendix B.7 returned NSEC RRs that prove the - requested data does not exist and no wildcard applies. The negative - reply is authenticated by verifying both NSEC RRs. - -C.8 DS Child Zone No Data Error - - The query in section Appendix B.8 returned NSEC RRs that shows the - requested was answered by a child server ("example" server). The - NSEC RR indicates the presence of an SOA RR, showing the answer is - from the child . Queries for the "example" DS RRset should be sent - to the parent servers ("root" servers). - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 56] - -Internet-Draft DNSSEC Protocol Modifications 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 57] - -Internet-Draft DNSSEC Protocol Modifications 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 58] - - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt deleted file mode 100644 index cfd3567f0a..0000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt +++ /dev/null @@ -1,2073 +0,0 @@ - - -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 - - - Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-07 - -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 document is part of a family of documents that describes the DNS - Security Extensions (DNSSEC). The DNS Security Extensions are a - collection of resource records and protocol modifications that - provide source authentication for the DNS. This document defines the - public key (DNSKEY), delegation signer (DS), resource record digital - - - -Arends, et al. Expires August 16, 2004 [Page 1] - -Internet-Draft DNSSEC Resource Records February 2004 - - - signature (RRSIG), and authenticated denial of existence (NSEC) - resource records. The purpose and format of each resource record is - described in detail, and an example of each resource record is given. - - This document obsoletes RFC 2535 and incorporates changes from all - updates to RFC 2535. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background and Related Documents . . . . . . . . . . . . . . 4 - 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4 - 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4 - 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5 - 2. The DNSKEY Resource Record . . . . . . . . . . . . . . . . . 6 - 2.1 DNSKEY RDATA Wire Format . . . . . . . . . . . . . . . . . . 6 - 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7 - 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7 - 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7 - 2.1.5 Notes on DNSKEY RDATA Design . . . . . . . . . . . . . . . . 7 - 2.2 The DNSKEY RR Presentation Format . . . . . . . . . . . . . 7 - 2.3 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . . . 8 - 3. The RRSIG Resource Record . . . . . . . . . . . . . . . . . 9 - 3.1 RRSIG RDATA Wire Format . . . . . . . . . . . . . . . . . . 9 - 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10 - 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10 - 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10 - 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11 - 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11 - 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11 - 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 12 - 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12 - 3.2 The RRSIG RR Presentation Format . . . . . . . . . . . . . . 13 - 3.3 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 13 - 4. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 15 - 4.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 - 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15 - 4.1.2 The Type Bit Maps Field . . . . . . . . . . . . . . . . . . 16 - 4.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 17 - 4.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 17 - 4.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 17 - 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 19 - 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 19 - 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 20 - 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 20 - - - -Arends, et al. Expires August 16, 2004 [Page 2] - -Internet-Draft DNSSEC Resource Records February 2004 - - - 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 20 - 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 20 - 5.2 Processing of DS RRs When Validating Responses . . . . . . . 20 - 5.3 The DS RR Presentation Format . . . . . . . . . . . . . . . 21 - 5.4 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 21 - 6. Canonical Form and Order of Resource Records . . . . . . . . 22 - 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 22 - 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 22 - 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 23 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 - 8. Security Considerations . . . . . . . . . . . . . . . . . . 26 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 - Normative References . . . . . . . . . . . . . . . . . . . . 28 - Informative References . . . . . . . . . . . . . . . . . . . 30 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30 - A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 32 - A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 32 - A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 32 - A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 33 - B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 34 - B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 35 - Intellectual Property and Copyright Statements . . . . . . . 36 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 3] - -Internet-Draft DNSSEC Resource Records February 2004 - - -1. Introduction - - The DNS Security Extensions (DNSSEC) introduce four new DNS resource - record types: DNSKEY, RRSIG, NSEC, and DS. This document defines the - purpose of each resource record (RR), the RR's RDATA format, and its - presentation format (ASCII representation). - -1.1 Background and Related Documents - - The reader is assumed to be familiar with the basic DNS concepts - described in RFC1034 [RFC1034], RFC1035 [RFC1035] and subsequent RFCs - that update them: RFC2136 [RFC2136], RFC2181 [RFC2181] and RFC2308 - [RFC2308]. - - This document is part of a family of documents that define the DNS - security extensions. The DNS security extensions (DNSSEC) are a - collection of resource records and DNS protocol modifications that - add source authentication and data integrity to the Domain Name - System (DNS). An introduction to DNSSEC and definitions of common - terms can be found in [I-D.ietf-dnsext-dnssec-intro]. A description - of DNS protocol modifications can be found in - [I-D.ietf-dnsext-dnssec-protocol]. This document defines the DNSSEC - resource records. - -1.2 Reserved Words - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -1.3 Editors' Notes - -1.3.1 Open Technical Issues - - The cryptographic algorithm types (Appendix A) requires input from - the working group. The DSA algorithm was moved to OPTIONAL. This - had strong consensus in workshops and various discussions and a - separate Internet-Draft solely to move DSA from MANDATORY to OPTIONAL - seemed excessive. This draft solicits input on that proposed change. - -1.3.2 Technical Changes or Corrections - - Please report technical corrections to dnssec-editors@east.isi.edu. - To assist the editors, please indicate the text in error and point - out the RFC that defines the correct behavior. For a technical - change where no RFC that defines the correct behavior, or if there's - more than one applicable RFC and the definitions conflict, please - post the issue to namedroppers. - - - -Arends, et al. Expires August 16, 2004 [Page 4] - -Internet-Draft DNSSEC Resource Records February 2004 - - - An example correction to dnssec-editors might be: Page X says - "DNSSEC RRs SHOULD be automatically returned in responses." This was - true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the - DNSSEC RR types MUST NOT be included in responses unless the resolver - indicated support for DNSSEC. - -1.3.3 Typos and Minor Corrections - - Please report any typos corrections to dnssec-editors@east.isi.edu. - To assist the editors, please provide enough context for us to find - the incorrect text quickly. - - An example message to dnssec-editors might be: page X says "the - DNSSEC standard has been in development for over 1 years". It - should read "over 10 years". - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 5] - -Internet-Draft DNSSEC Resource Records February 2004 - - -2. The DNSKEY Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). The public keys are stored in DNSKEY - resource records and are used in the DNSSEC authentication process - described in [I-D.ietf-dnsext-dnssec-protocol]: A zone signs its - authoritative RRsets using a private key and stores the corresponding - public key in a DNSKEY RR. A resolver can then use the public key to - authenticate signatures covering the RRsets in the zone. - - The DNSKEY RR is not intended as a record for storing arbitrary - public keys, and MUST NOT be used to store certificates or public - keys that do not directly relate to the DNS infrastructure. - - The Type value for the DNSKEY RR type is 48. - - The DNSKEY RR is class independent. - - The DNSKEY RR has no special TTL requirements. - -2.1 DNSKEY RDATA Wire Format - - The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1 - octet Protocol Field, a 1 octet Algorithm Field, and the Public Key - Field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Protocol | Algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Public Key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -2.1.1 The Flags Field - - Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1, - then the DNSKEY record holds a DNS zone key and the DNSKEY RR's owner - name MUST be the name of a zone. If bit 7 has value 0, then the - DNSKEY record holds some other type of DNS public key, such as a - public key used by TKEY and MUST NOT be used to verify RRSIGs that - cover RRsets. - - Bit 15 of the Flags field is the Secure Entry Point flag, described - in [I-D.ietf-dnsext-keyrr-key-signing-flag]. If bit 15 has value 1, - - - -Arends, et al. Expires August 16, 2004 [Page 6] - -Internet-Draft DNSSEC Resource Records February 2004 - - - then the DNSKEY record holds a key intended for use as a secure entry - point. This flag is only intended to be to a hint to zone signing or - debugging software as to the intended use of this DNSKEY record; - security-aware resolvers MUST NOT alter their behavior during the - signature validation process in any way based on the setting of this - bit. - - Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon - creation of the DNSKEY RR, and MUST be ignored upon reception. - -2.1.2 The Protocol Field - - The Protocol Field MUST have value 3 and MUST be treated as invalid - during signature verification if found to be some value other than 3. - -2.1.3 The Algorithm Field - - The Algorithm field identifies the public key's cryptographic - algorithm and determines the format of the Public Key field. A list - of DNSSEC algorithm types can be found in Appendix A.1 - -2.1.4 The Public Key Field - - The Public Key Field holds the public key material. The format - depends on the algorithm of the key being stored and are described in - separate documents. - -2.1.5 Notes on DNSKEY RDATA Design - - Although the Protocol Field always has value 3, it is retained for - backward compatibility with early versions of the KEY record. - -2.2 The DNSKEY RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Flag field MUST be represented as an unsigned decimal integer - with a value of 0, 256, or 257. - - The Protocol Field MUST be represented as an unsigned decimal integer - with a value of 3. - - The Algorithm field MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Public Key field MUST be represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - - - -Arends, et al. Expires August 16, 2004 [Page 7] - -Internet-Draft DNSSEC Resource Records February 2004 - - - definition of Base64 encoding, see [RFC1521] Section 5.2. - -2.3 DNSKEY RR Example - - The following DNSKEY RR stores a DNS zone key for example.com. - - example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 - Cbl+BBZH4b/0PY1kxkmvHjcZc8no - kfzj31GajIQKY+5CptLr3buXA10h - WqTkF7H6RfoRqXQeogmMHfpftf6z - Mv1LyBUgia7za6ZEzOJBOztyvhjL - 742iU/TpPSEDhm2SNKLijfUppn1U - aNvv4w== ) - - The first four text fields specify the owner name, TTL, Class, and RR - type (DNSKEY). Value 256 indicates that the Zone Key bit (bit 7) in - the Flags field has value 1. Value 3 is the fixed Protocol value. - Value 5 indicates the public key algorithm. Appendix A.1 identifies - algorithm type 5 as RSA/SHA1 and indicates that the format of the - RSA/SHA1 public key field is defined in [RFC3110]. The remaining - text is a Base64 encoding of the public key. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 8] - -Internet-Draft DNSSEC Resource Records February 2004 - - -3. The RRSIG Resource Record - - DNSSEC uses public key cryptography to sign and authenticate DNS - resource record sets (RRsets). Digital signatures are stored in - RRSIG resource records and are used in the DNSSEC authentication - process described in [I-D.ietf-dnsext-dnssec-protocol]. A - security-aware resolver can use these RRSIG RRs to authenticate - RRsets from the zone. The RRSIG RR MUST only be used to carry - verification material (digital signatures) used to secure DNS - operations. - - An RRSIG record contains the signature for an RRset with a particular - name, class, and type. The RRSIG RR specifies a validity interval - for the signature and uses the Algorithm, the Signer's Name, and the - Key Tag to identify the DNSKEY RR containing the public key that a - resolver can use to verify the signature. - - Because every authoritative RRset in a zone must be protected by a - digital signature, RRSIG RRs must be present for names containing a - CNAME RR. This is a change to the traditional DNS specification - [RFC1034] that stated that if a CNAME is present for a name, it is - the only type allowed at that name. A RRSIG and NSEC (see Section 4) - MUST exist for the same name as a CNAME resource record in a secure - zone. - - The Type value for the RRSIG RR type is 46. - - The RRSIG RR is class independent. - - An RRSIG RR MUST have the same class as the RRset it covers. - - The TTL value of an RRSIG RR SHOULD match the TTL value of the RRset - it covers. This is an exception to the [RFC2181] rules for TTL - values of individual RRs within a RRset: individual RRSIG with the - same owner name will have different TTL values if the RRsets that - they cover have different TTL values. - -3.1 RRSIG RDATA Wire Format - - The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a - 1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original - TTL field, a 4 octet Signature Expiration field, a 4 octet Signature - Inception field, a 2 octet Key tag, the Signer's Name field, and the - Signature field. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - -Arends, et al. Expires August 16, 2004 [Page 9] - -Internet-Draft DNSSEC Resource Records February 2004 - - - | Type Covered | Algorithm | Labels | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original TTL | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Expiration | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Signature Inception | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Signature / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -3.1.1 The Type Covered Field - - The Type Covered field identifies the type of the RRset which is - covered by this RRSIG record. - -3.1.2 The Algorithm Number Field - - The Algorithm Number field identifies the cryptographic algorithm - used to create the signature. A list of DNSSEC algorithm types can - be found in Appendix A.1 - -3.1.3 The Labels Field - - The Labels field specifies the number of labels in the original RRSIG - RR owner name. The significance of this field is that from it a - verifier can determine if the answer was synthesized from a wildcard. - If so, it can be used to determine what owner name was used in - generating the signature. - - To validate a signature, the validator needs the original owner name - that was used to create the signature. If the original owner name - contains a wildcard label ("*"), the owner name may have been - expanded by the server during the response process, in which case the - validator will need to reconstruct the original owner name in order - to validate the signature. [I-D.ietf-dnsext-dnssec-protocol] - describes how to use the Labels field to reconstruct the original - owner name. - - The value of the Labels field MUST NOT count either the null (root) - label that terminates the owner name or the wildcard label (if - - - -Arends, et al. Expires August 16, 2004 [Page 10] - -Internet-Draft DNSSEC Resource Records February 2004 - - - present). The value of the Labels field MUST be less than or equal - to the number of labels in the RRSIG owner name. For example, - "www.example.com." has a Labels field value of 3, and - "*.example.com." has a Labels field value of 2. Root (".") has a - Labels field value of 0. - - Although the wildcard label is not included in the count stored in - the Labels field of the RRSIG RR, the wildcard label is part of the - RRset's owner name when generating or verifying the signature. - -3.1.4 Original TTL Field - - The Original TTL field specifies the TTL of the covered RRset as it - appears in the authoritative zone. - - The Original TTL field is necessary because a caching resolver - decrements the TTL value of a cached RRset. In order to validate a - signature, a resolver requires the original TTL. - [I-D.ietf-dnsext-dnssec-protocol] describes how to use the Original - TTL field value to reconstruct the original TTL. - -3.1.5 Signature Expiration and Inception Fields - - The Signature Expiration and Inception fields specify a validity - period for the signature. The RRSIG record MUST NOT be used for - authentication prior to the inception date and MUST NOT be used for - authentication after the expiration date. - - Signature Expiration and Inception field values are in POSIX.1 time - format: a 32-bit unsigned number of seconds elapsed since 1 January - 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The - longest interval which can be expressed by this format without - wrapping is approximately 136 years. An RRSIG RR can have an - Expiration field value which is numerically smaller than the - Inception field value if the expiration field value is near the - 32-bit wrap-around point or if the signature is long lived. Because - of this, all comparisons involving these fields MUST use "Serial - number arithmetic" as defined in [RFC1982]. As a direct consequence, - the values contained in these fields cannot refer to dates more than - 68 years in either the past or the future. - -3.1.6 The Key Tag Field - - The Key Tag field contains the key tag value of the DNSKEY RR that - validates this signature. Appendix B explains how to calculate Key - Tag values. - - - - - -Arends, et al. Expires August 16, 2004 [Page 11] - -Internet-Draft DNSSEC Resource Records February 2004 - - -3.1.7 The Signer's Name Field - - The Signer's Name field value identifies the owner name of the DNSKEY - RR which a security-aware resolver should use to validate this - signature. The Signer's Name field MUST contain the name of the zone - of the covered RRset. A sender MUST NOT use DNS name compression on - the Signer's Name field when transmitting a RRSIG RR. A receiver - which receives an RRSIG RR containing a compressed Signer's Name - field SHOULD decompress the field value. - -3.1.8 The Signature Field - - The Signature field contains the cryptographic signature which covers - the RRSIG RDATA (excluding the Signature field) and the RRset - specified by the RRSIG owner name, RRSIG class, and RRSIG Type - Covered field. The format of this field depends on the algorithm in - use and these formats are described in separate companion documents. - -3.1.8.1 Signature Calculation - - A signature covers the RRSIG RDATA (excluding the Signature Field) - and covers the data RRset specified by the RRSIG owner name, RRSIG - class, and RRSIG Type Covered fields. The RRset is in canonical form - (see Section 6) and the set RR(1),...RR(n) is signed as follows: - - signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where - - "|" denotes concatenation; - - RRSIG_RDATA is the wire format of the RRSIG RDATA fields - with the Signer's Name field in canonical form and - the Signature field excluded; - - RR(i) = owner | class | type | TTL | RDATA length | RDATA; - - "owner" is the fully qualified owner name of the RRset in - canonical form (for RRs with wildcard owner names, the - wildcard label is included in the owner name); - - Each RR MUST have the same owner name as the RRSIG RR; - - Each RR MUST have the same class as the RRSIG RR; - - Each RR in the RRset MUST have the RR type listed in the - RRSIG RR's Type Covered field; - - Each RR in the RRset MUST have the TTL listed in the - RRSIG Original TTL Field; - - - -Arends, et al. Expires August 16, 2004 [Page 12] - -Internet-Draft DNSSEC Resource Records February 2004 - - - Any DNS names in the RDATA field of each RR MUST be in - canonical form; and - - The RRset MUST be sorted in canonical order. - - -3.2 The RRSIG RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Type Covered field value MUST be represented either as an - unsigned decimal integer or as the mnemonic for the covered RR type. - - The Algorithm field value MUST be represented either as an unsigned - decimal integer or as an algorithm mnemonic as specified in Appendix - A.1. - - The Labels field value MUST be represented as an unsigned decimal - integer. - - The Original TTL field value MUST be represented as an unsigned - decimal integer. - - The Signature Expiration Time and Inception Time field values MUST be - represented in the form YYYYMMDDHHmmSS in UTC, where: - - YYYY is the year (0000-9999, but see Section 3.1.5); - - MM is the month number (01-12); - - DD is the day of the month (01-31); - - HH is the hour in 24 hours notation (00-23); - - mm is the minute (00-59); - - SS is the second (00-59). - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Signer's Name field value MUST be represented as a domain name. - - The Signature field is represented as a Base64 encoding of the - signature. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding see [RFC1521] Section 5.2. - -3.3 RRSIG RR Example - - - - -Arends, et al. Expires August 16, 2004 [Page 13] - -Internet-Draft DNSSEC Resource Records February 2004 - - - The following an RRSIG RR stores the signature for the A RRset of - host.example.com: - - host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( - 20030220173103 2642 example.com. - oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr - PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o - B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t - GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG - J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) - - The first four fields specify the owner name, TTL, Class, and RR type - (RRSIG). The "A" represents the Type Covered field. The value 5 - identifies the algorithm used (RSA/SHA1) to create the signature. - The value 3 is the number of Labels in the original owner name. The - value 86400 in the RRSIG RDATA is the Original TTL for the covered A - RRset. 20030322173103 and 20030220173103 are the expiration and - inception dates, respectively. 2642 is the Key Tag, and example.com. - is the Signer's Name. The remaining text is a Base64 encoding of the - signature. - - Note that combination of RRSIG RR owner name, class, and Type Covered - indicate that this RRSIG covers the "host.example.com" A RRset. The - Label value of 3 indicates that no wildcard expansion was used. The - Algorithm, Signer's Name, and Key Tag indicate this signature can be - authenticated using an example.com zone DNSKEY RR whose algorithm is - 5 and key tag is 2642. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 14] - -Internet-Draft DNSSEC Resource Records February 2004 - - -4. The NSEC Resource Record - - The NSEC resource record lists two separate things: the owner name of - the next authoritative RRset in the canonical ordering of the zone, - and the set of RR types present at the NSEC RR's owner name. The - complete set of NSEC RRs in a zone both indicate which authoritative - RRsets exist in a zone and also form a chain of authoritative owner - names in the zone. This information is used to provide authenticated - denial of existence for DNS data, as described in - [I-D.ietf-dnsext-dnssec-protocol]. - - Because every authoritative name in a zone must be part of the NSEC - chain, NSEC RRs must be present for names containing a CNAME RR. - This is a change to the traditional DNS specification [RFC1034] that - stated that if a CNAME is present for a name, it is the only type - allowed at that name. An RRSIG (see Section 3) and NSEC MUST exist - for the same name as a CNAME resource record in a secure zone. - - The type value for the NSEC RR is 47. - - The NSEC RR is class independent. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirt of negative caching [RFC2308]. - -4.1 NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Type Bit Maps / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -4.1.1 The Next Domain Name Field - - The Next Domain Name field contains the owner name of the next - authoritative owner name in the canonical ordering of the zone; see - Section 6.1 for an explanation of canonical ordering. The value of - the Next Domain Name field in the last NSEC record in the zone is the - name of the zone apex (the owner name of the zone's SOA RR). - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. A receiver which receives an - - - -Arends, et al. Expires August 16, 2004 [Page 15] - -Internet-Draft DNSSEC Resource Records February 2004 - - - NSEC RR containing a compressed Next Domain Name field SHOULD - decompress the field value. - - Owner names of RRsets not authoritative for the given zone (such as - glue records) MUST NOT be listed in the Next Domain Name unless at - least one authoritative RRset exists at the same owner name. - -4.1.2 The Type Bit Maps Field - - The Type Bit Maps field identifies the RRset types which exist at the - NSEC RR's owner name. - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that has - at least one active RR type is encoded using a single octet window - number (from 0 to 255), a single octet bitmap length (from 1 to 32) - indicating the number of octets used for the window block's bitmap, - and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC RR RDATA in increasing numerical - order. - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - where "|" denotes concatenation. - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC - RR's owner name. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC RR's owner name. - - Since bit 0 in window block 0 refers to the non-existent RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing pseudo-types MUST be set to 0, since they do not - appear in zone data. If encountered, they MUST be ignored upon - reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - - - -Arends, et al. Expires August 16, 2004 [Page 16] - -Internet-Draft DNSSEC Resource Records February 2004 - - - interpreted as zero octets. - - A zone MUST NOT generate an NSEC RR for any domain name that only - holds glue records. - -4.1.3 Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for purposes of generating NSEC RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - [I-D.ietf-dnsext-dnssec-protocol] describes the impact of wildcards - on authenticated denial of existence. - -4.2 The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The Type Bit Maps field is represented as a sequence of RR type - mnemonics. When the mnemonic is not known, the TYPE representation - as described in [RFC3597] (section 5) MUST be used. - -4.3 NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. ( - A MX RRSIG NSEC TYPE1234 ) - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, - and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and - TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - - - -Arends, et al. Expires August 16, 2004 [Page 17] - -Internet-Draft DNSSEC Resource Records February 2004 - - - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the resolver can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or could - be used to prove there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - [I-D.ietf-dnsext-dnssec-protocol]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 18] - -Internet-Draft DNSSEC Resource Records February 2004 - - -5. The DS Resource Record - - The DS Resource Record refers to a DNSKEY RR and is used in the DNS - DNSKEY authentication process. A DS RR refers to a DNSKEY RR by - storing the key tag, algorithm number, and a digest of the DNSKEY RR. - Note that while the digest should be sufficient to identify the - public key, storing the key tag and key algorithm helps make the - identification process more efficient. By authenticating the DS - record, a resolver can authenticate the DNSKEY RR to which the DS - record points. The key authentication process is described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The DS RR and its corresponding DNSKEY RR have the same owner name, - but they are stored in different locations. The DS RR appears only - on the upper (parental) side of a delegation, and is authoritative - data in the parent zone. For example, the DS RR for "example.com" is - stored in the "com" zone (the parent zone) rather than in the - "example.com" zone (the child zone). The corresponding DNSKEY RR is - stored in the "example.com" zone (the child zone). This simplifies - DNS zone management and zone signing, but introduces special response - processing requirements for the DS RR; these are described in - [I-D.ietf-dnsext-dnssec-protocol]. - - The type number for the DS record is 43. - - The DS resource record is class independent. - - The DS RR has no special TTL requirements. - -5.1 DS RDATA Wire Format - - The RDATA for a DS RR consists of a 2 octet Key Tag field, a one - octet Algorithm field, a one octet Digest Type field, and a Digest - field. - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | Digest Type | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 19] - -Internet-Draft DNSSEC Resource Records February 2004 - - -5.1.1 The Key Tag Field - - The Key Tag field lists the key tag of the DNSKEY RR referred to by - the DS record. - - The Key Tag used by the DS RR is identical to the Key Tag used by - RRSIG RRs. Appendix B describes how to compute a Key Tag. - -5.1.2 The Algorithm Field - - The Algorithm field lists the algorithm number of the DNSKEY RR - referred to by the DS record. - - The algorithm number used by the DS RR is identical to the algorithm - number used by RRSIG and DNSKEY RRs. Appendix A.1 lists the algorithm - number types. - -5.1.3 The Digest Type Field - - The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY - RR. The Digest Type field identifies the algorithm used to construct - the digest. Appendix A.2 lists the possible digest algorithm types. - -5.1.4 The Digest Field - - The DS record refers to a DNSKEY RR by including a digest of that - DNSKEY RR. - - The digest is calculated by concatenating the canonical form of the - fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA, - and then applying the digest algorithm. - - digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA); - - "|" denotes concatenation - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key. - - - The size of the digest may vary depending on the digest algorithm and - DNSKEY RR size. As of the time of writing, the only defined digest - algorithm is SHA-1, which produces a 20 octet digest. - -5.2 Processing of DS RRs When Validating Responses - - The DS RR links the authentication chain across zone boundaries, so - the DS RR requires extra care in processing. The DNSKEY RR referred - to in the DS RR MUST be a DNSSEC zone key. The DNSKEY RR Flags MUST - - - -Arends, et al. Expires August 16, 2004 [Page 20] - -Internet-Draft DNSSEC Resource Records February 2004 - - - have Flags bit 7 set to value 1. If the key tag does not indicate a - DNSSEC zone key, the DS RR (and DNSKEY RR it references) MUST NOT be - used in the validation process. - -5.3 The DS RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Key Tag field MUST be represented as an unsigned decimal integer. - - The Algorithm field MUST be represented either as an unsigned decimal - integer or as an algorithm mnemonic specified in Appendix A.1. - - The Digest Type field MUST be represented as an unsigned decimal - integer. - - The Digest MUST be represented as a sequence of case-insensitive - hexadecimal digits. Whitespace is allowed within the hexadecimal - text. - -5.4 DS RR Example - - The following example shows a DNSKEY RR and its corresponding DS RR. - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A - 98631FAD1A292118 ) - - - The first four text fields specify the name, TTL, Class, and RR type - (DS). Value 60485 is the key tag for the corresponding - "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm - used by this "dskey.example.com." DNSKEY RR. The value 1 is the - algorithm used to construct the digest, and the rest of the RDATA - text is the digest in hexadecimal. - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 21] - -Internet-Draft DNSSEC Resource Records February 2004 - - -6. Canonical Form and Order of Resource Records - - This section defines a canonical form for resource records, a - canonical ordering of DNS names, and a canonical ordering of resource - records within an RRset. A canonical name order is required to - construct the NSEC name chain. A canonical RR form and ordering - within an RRset are required to construct and verify RRSIG RRs. - -6.1 Canonical DNS Name Order - - For purposes of DNS security, owner names are ordered by treating - individual labels as unsigned left-justified octet strings. The - absence of a octet sorts before a zero value octet, and upper case - US-ASCII letters are treated as if they were lower case US-ASCII - letters. - - To compute the canonical ordering of a set of DNS names, start by - sorting the names according to their most significant (rightmost) - labels. For names in which the most significant label is identical, - continue sorting according to their next most significant label, and - so forth. - - For example, the following names are sorted in canonical DNS name - order. The most significant label is "example". At this level, - "example" sorts first, followed by names ending in "a.example", then - names ending "z.example". The names within each level are sorted in - the same way. - - example - a.example - yljkjljk.a.example - Z.a.example - zABC.a.EXAMPLE - z.example - \001.z.example - *.z.example - \200.z.example - - -6.2 Canonical RR Form - - For purposes of DNS security, the canonical form of an RR is the wire - format of the RR where: - - 1. Every domain name in the RR is fully expanded (no DNS name - compression) and fully qualified; - - 2. All uppercase US-ASCII letters in the owner name of the RR are - - - -Arends, et al. Expires August 16, 2004 [Page 22] - -Internet-Draft DNSSEC Resource Records February 2004 - - - replaced by the corresponding lowercase US-ASCII letters; - - 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, - HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, - SRV, DNAME, A6, RRSIG or NSEC, all uppercase US-ASCII letters in - the DNS names contained within the RDATA are replaced by the - corresponding lowercase US-ASCII letters; - - 4. If the owner name of the RR is a wildcard name, the owner name is - in its original unexpanded form, including the "*" label (no - wildcard substitution); and - - 5. The RR's TTL is set to its original value as it appears in the - originating authoritative zone or the Original TTL field of the - covering RRSIG RR. - - -6.3 Canonical RR Ordering Within An RRset - - For purposes of DNS security, RRs with the same owner name, class, - and type are sorted by treating the RDATA portion of the canonical - form of each RR as a left-justified unsigned octet sequence where the - absence of an octet sorts before a zero octet. - - [RFC2181] specifies that an RRset is not allowed to contain duplicate - records (multiple RRs with the same owner name, class, type, and - RDATA). Therefore, if an implementation detects duplicate RRs during - RRset canonicalization, the implementation MUST treat this as a - protocol error. If the implementation chooses to handle this - protocol error in the spirit of the robustness principle (being - liberal in what it accepts), the implementation MUST remove all but - one of the duplicate RR(s) for purposes of calculating the canonical - form of the RRset. - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 23] - -Internet-Draft DNSSEC Resource Records February 2004 - - -7. IANA Considerations - - This document introduces no new IANA considerations, because all of - the protocol parameters used in this document have already been - assigned by previous specifications. However, since the evolution of - DNSSEC has been long and somewhat convoluted, this section attempts - to describe the current state of the IANA registries and other - protocol parameters which are (or once were) related to DNSSEC. - - Please refer to [I-D.ietf-dnsext-dnssec-protocol] for additional IANA - considerations. - - DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to - the SIG, KEY, and NXT RRs, respectively. [RFC3658] assigned DNS - Resource Record Type 43 to DS. - [I-D.ietf-dnsext-dnssec-2535typecode-change] assigned types 46, - 47, and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively. - [I-D.ietf-dnsext-dnssec-2535typecode-change] also marked type 30 - (NXT) as Obsolete, and restricted use of types 24 (SIG) and 25 - (KEY) to the "SIG(0)" transaction security protocol described in - [RFC2931] and the transaction KEY Resource Record described in - [RFC2930]. - - DNS Security Algorithm Numbers: [RFC2535] created an IANA registry - for DNSSEC Resource Record Algorithm field numbers, and assigned - values 1-4 and 252-255. [RFC3110] assigned value 5. - [I-D.ietf-dnsext-dnssec-2535typecode-change] altered this registry - to include flags for each entry regarding its use with the DNS - security extensions. Each algorithm entry could refer to an - algorithm that can be used for zone signing, transaction security - (see [RFC2931]) or both. Values 6-251 are available for assignment - by IETF standards action. See Appendix A for a full listing of the - DNS Security Algorithm Numbers entries at the time of writing and - their status of use in DNSSEC. - - [RFC3658] created an IANA registry for DNSSEC DS Digest Types, and - assigned value 0 to reserved and value 1 to SHA-1. - - KEY Protocol Values: [RFC2535] created an IANA Registry for KEY - Protocol Values, but [RFC3445] re-assigned all assigned values - other than 3 to reserved and closed this IANA registry. The - registry remains closed, and all KEY and DNSKEY records are - required to have Protocol Octet value of 3. - - Flag bits in the KEY and DNSKEY RRs: - [I-D.ietf-dnsext-dnssec-2535typecode-change] created an IANA - registry for the DNSSEC KEY and DNSKEY RR flag bits. Initially, - this registry only contains an assignment for bit 7 (the ZONE bit) - - - -Arends, et al. Expires August 16, 2004 [Page 24] - -Internet-Draft DNSSEC Resource Records February 2004 - - - and a reservation for bit 15 for the Secure Entry Point flag (SEP - bit) [I-D.ietf-dnsext-keyrr-key-signing-flag]. Bits 0-6 and 8-14 - are available for assignment by IETF Standards Action. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 25] - -Internet-Draft DNSSEC Resource Records February 2004 - - -8. Security Considerations - - This document describes the format of four DNS resource records used - by the DNS security extensions, and presents an algorithm for - calculating a key tag for a public key. Other than the items - described below, the resource records themselves introduce no - security considerations. Please see [I-D.ietf-dnsext-dnssec-intro] - and [I-D.ietf-dnsext-dnssec-protocol] for additional security - considerations related to the use of these records. - - The DS record points to a DNSKEY RR using a cryptographic digest, the - key algorithm type and a key tag. The DS record is intended to - identify an existing DNSKEY RR, but it is theoretically possible for - an attacker to generate a DNSKEY that matches all the DS fields. The - probability of constructing such a matching DNSKEY depends on the - type of digest algorithm in use. The only currently defined digest - algorithm is SHA-1, and the working group believes that constructing - a public key which would match the algorithm, key tag, and SHA-1 - digest given in a DS record would be a sufficiently difficult problem - that such an attack is not a serious threat at this time. - - The key tag is used to help select DNSKEY resource records - efficiently, but it does not uniquely identify a single DNSKEY - resource record. It is possible for two distinct DNSKEY RRs to have - the same owner name, the same algorithm type, and the same key tag. - An implementation which used only the key tag to select a DNSKEY RR - might select the wrong public key in some circumstances. - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 26] - -Internet-Draft DNSSEC Resource Records February 2004 - - -9. Acknowledgments - - This document was created from the input and ideas of the members of - the DNS Extensions Working Group and working group mailing list. The - editors would like to express their thanks for the comments and - suggestions received during the revision of these security extension - specifications. While explicitly listing everyone who has - contributed during the decade during which DNSSEC has been under - development would be an impossible task, - [I-D.ietf-dnsext-dnssec-intro] includes a list of some of the - participants who were kind enough to comment on these documents. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 27] - -Internet-Draft DNSSEC Resource Records 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. - - [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet - Mail Extensions) Part One: Mechanisms for Specifying and - Describing the Format of Internet Message Bodies", RFC - 1521, September 1993. - - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", RFC 2136, - April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS - NCACHE)", RFC 2308, March 1998. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( - SIG(0)s)", RFC 2931, September 2000. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY - Resource Record (RR)", RFC 3445, December 2002. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record - (RR)", RFC 3658, December 2003. - - [I-D.ietf-dnsext-dnssec-intro] - - - -Arends, et al. Expires August 16, 2004 [Page 28] - -Internet-Draft DNSSEC Resource Records February 2004 - - - Arends, R., Austein, R., Larson, M., Massey, D. and S. - Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-09 (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. - - [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. - - [I-D.ietf-dnsext-dnssec-2535typecode-change] - Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06 - (work in progress), December 2003. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 29] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Informative References - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - -Authors' Addresses - - Roy Arends - Telematica Instituut - Drienerlolaan 5 - 7522 NB Enschede - NL - - EMail: roy.arends@telin.nl - - - 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 30] - -Internet-Draft DNSSEC Resource Records 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 31] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Appendix A. DNSSEC Algorithm and Digest Types - - The DNS security extensions are designed to be independent of the - underlying cryptographic algorithms. The DNSKEY, RRSIG, and DS - resource records all use a DNSSEC Algorithm Number to identify the - cryptographic algorithm in use by the resource record. The DS - resource record also specifies a Digest Algorithm Number to identify - the digest algorithm used to construct the DS record. The currently - defined Algorithm and Digest Types are listed below. Additional - Algorithm or Digest Types could be added as advances in cryptography - warrant. - - A DNSSEC aware resolver or name server MUST implement all MANDATORY - algorithms. - -A.1 DNSSEC Algorithm Types - - The DNSKEY, RRSIG, and DS RRs use an 8-bit number used to identify - the security algorithm being used. These values are stored in the - "Algorithm number" field in the resource record RDATA. - - Some algorithms are usable only for zone signing (DNSSEC), some only - for transaction security mechanisms (SIG(0) and TSIG), and some for - both. Those usable for zone signing may appear in DNSKEY, RRSIG, and - DS RRs. Those usable for transaction security would be present in - SIG(0) and KEY RRs as described in [RFC2931] - - Zone - Value Algorithm [Mnemonic] Signing References Status - ----- -------------------- --------- ---------- --------- - 0 reserved - 1 RSA/MD5 [RSAMD5] n RFC 2537 NOT RECOMMENDED - 2 Diffie-Hellman [DH] n RFC 2539 - - 3 DSA/SHA-1 [DSA] y RFC 2536 OPTIONAL - 4 Elliptic Curve [ECC] TBA - - 5 RSA/SHA-1 [RSASHA1] y RFC 3110 MANDATORY - 252 Indirect [INDIRECT] n - - 253 Private [PRIVATEDNS] y see below OPTIONAL - 254 Private [PRIVATEOID] y see below OPTIONAL - 255 reserved - - 6 - 251 Available for assignment by IETF Standards Action. - -A.1.1 Private Algorithm Types - - Algorithm number 253 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with a wire encoded - - - -Arends, et al. Expires August 16, 2004 [Page 32] - -Internet-Draft DNSSEC Resource Records February 2004 - - - domain name, which MUST NOT be compressed. The domain name indicates - the private algorithm to use and the remainder of the public key area - is determined by that algorithm. Entities should only use domain - names they control to designate their private algorithms. - - Algorithm number 254 is reserved for private use and will never be - assigned to a specific algorithm. The public key area in the DNSKEY - RR and the signature area in the RRSIG RR begin with an unsigned - length byte followed by a BER encoded Object Identifier (ISO OID) of - that length. The OID indicates the private algorithm in use and the - remainder of the area is whatever is required by that algorithm. - Entities should only use OIDs they control to designate their private - algorithms. - -A.2 DNSSEC Digest Types - - A "Digest Type" field in the DS resource record types identifies the - cryptographic digest algorithm used by the resource record. The - following table lists the currently defined digest algorithm types. - - VALUE Algorithm STATUS - 0 Reserved - - 1 SHA-1 MANDATORY - 2-255 Unassigned - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 33] - -Internet-Draft DNSSEC Resource Records February 2004 - - -Appendix B. Key Tag Calculation - - The Key Tag field in the RRSIG and DS resource record types provides - a mechanism for selecting a public key efficiently. In most cases, a - combination of owner name, algorithm, and key tag can efficiently - identify a DNSKEY record. Both the RRSIG and DS resource records - have corresponding DNSKEY records. The Key Tag field in the RRSIG - and DS records can be used to help select the corresponding DNSKEY RR - efficiently when more than one candidate DNSKEY RR is available. - - However, it is essential to note that the key tag is not a unique - identifier. It is theoretically possible for two distinct DNSKEY RRs - to have the same owner name, the same algorithm, and the same key - tag. The key tag is used to limit the possible candidate keys, but it - does not uniquely identify a DNSKEY record. Implementations MUST NOT - assume that the key tag uniquely identifies a DNSKEY RR. - - The key tag is the same for all DNSKEY algorithm types except - algorithm 1 (please see Appendix B.1 for the definition of the key - tag for algorithm 1). The key tag algorithm is the sum of the wire - format of the DNSKEY RDATA broken into 2 octet groups. First the - RDATA (in wire format) is treated as a series of 2 octet groups, - these groups are then added together ignoring any carry bits. A - reference implementation of the key tag algorithm is as an ANSI C - function is given below with the RDATA portion of the DNSKEY RR is - used as input. It is not necessary to use the following reference - code verbatim, but the numerical value of the Key Tag MUST be - identical to what the reference implementation would generate for the - same input. - - Please note that the algorithm for calculating the Key Tag is almost - but not completely identical to the familiar ones complement checksum - used in many other Internet protocols. Key Tags MUST be calculated - using the algorithm described here rather than the ones complement - checksum. - - The following ANSI C reference implementation calculates the value of - a Key Tag. This reference implementation applies to all algorithm - types except algorithm 1 (see Appendix B.1). The input is the wire - format of the RDATA portion of the DNSKEY RR. The code is written - for clarity, not efficiency. - - /* - * Assumes that int is at least 16 bits. - * First octet of the key tag is the most significant 8 bits of the - * return value; - * Second octet of the key tag is the least significant 8 bits of the - * return value. - - - -Arends, et al. Expires August 16, 2004 [Page 34] - -Internet-Draft DNSSEC Resource Records February 2004 - - - */ - - unsigned int - keytag ( - unsigned char key[], /* the RDATA part of the DNSKEY RR */ - unsigned int keysize /* the RDLENGTH */ - ) - { - unsigned long ac; /* assumed to be 32 bits or larger */ - int i; /* loop index */ - - for ( ac = 0, i = 0; i < keysize; ++i ) - ac += (i & 1) ? key[i] : key[i] << 8; - ac += (ac >> 16) & 0xFFFF; - return ac & 0xFFFF; - } - - -B.1 Key Tag for Algorithm 1 (RSA/MD5) - - The key tag for algorithm 1 (RSA/MD5) is defined differently than the - key tag for all other algorithms, for historical reasons. For a - DNSKEY RR with algorithm 1, the key tag is defined to be the most - significant 16 bits of the least significant 24 bits in the public - key modulus (in other words, the 4th to last and 3rd to last octets - of the public key modulus). - - Please note that Algorithm 1 is NOT RECOMMENDED. - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 16, 2004 [Page 35] - -Internet-Draft DNSSEC Resource Records 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 36] - -Internet-Draft DNSSEC Resource Records 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 37] - - diff --git a/doc/draft/draft-ietf-dnsext-mdns-29.txt b/doc/draft/draft-ietf-dnsext-mdns-29.txt deleted file mode 100644 index 1a51b690d3..0000000000 --- a/doc/draft/draft-ietf-dnsext-mdns-29.txt +++ /dev/null @@ -1,1555 +0,0 @@ - - -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-dnsext-nsec-rdata-05.txt b/doc/draft/draft-ietf-dnsext-nsec-rdata-05.txt deleted file mode 100644 index acdf4581ed..0000000000 --- a/doc/draft/draft-ietf-dnsext-nsec-rdata-05.txt +++ /dev/null @@ -1,503 +0,0 @@ - - -DNS Extensions Working Group J. Schlyter, Ed. -Internet-Draft March 11, 2004 -Updates: RFC 2535, RFC TCR -Expires: September 9, 2004 - - - DNSSEC NSEC RDATA Format - draft-ietf-dnsext-nsec-rdata-05.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 September 9, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2004). All Rights Reserved. - -Abstract - - This document redefines the wire format of the "Type Bit Map" field - in the NSEC resource record RDATA format to cover the full RR type - space. - - - - - - - - - - - -Schlyter Expires September 9, 2004 [Page 1] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3 - 2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4 - 2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4 - 2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4 - 2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5 - 2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5 - 2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 6 - 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 - Normative References . . . . . . . . . . . . . . . . . . . . 6 - Informational References . . . . . . . . . . . . . . . . . . 7 - Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 - A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 - Intellectual Property and Copyright Statements . . . . . . . 8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires September 9, 2004 [Page 2] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - -1. Introduction - - The NSEC [6] Resource Record (RR) is used for authenticated proof of - the non-existence of DNS owner names and types. The NSEC RR is based - on the NXT RR as described in RFC 2535 [3], and is similar except for - the name and typecode. The RDATA format for the NXT RR had a - limitation in that, without using a yet undefined extension - mechanism, the the RDATA could only carry information about the - existence of the first 127 types. - - To prevent the introduction of an extension mechanism into a deployed - base of DNSSEC aware servers and resolvers, once the first 127 type - codes are allocated, this document redefines the wire format of the - "Type Bit Map" field in the NSEC RDATA to cover the full RR type - space. - - This document introduces a new format for the type bit map. The - properties of the type bit map format are that it can cover the full - possible range of typecodes, that it is relatively economic in the - amount of space it uses for the common case of a few types with an - owner name, that it can represent owner names with all possible types - present in packets of approximately 8.5 kilobytes and that the - representation is simple to implement. Efficient searching of the - type bitmap for the presence of certain types is not a requirement. - - For convenience and completeness this document presents the syntax - and semantics for the NSEC RR based on the specification in RFC 2535 - [3] and as updated by RFC TCR [6], thereby not introducing changes - except for the syntax of the type bit map. - - This document updates RFC 2535 [3] and RFC TCR [6]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - -2. The NSEC Resource Record - - The NSEC resource record lists two separate things: the owner name of - the next RRset in the canonical ordering of the zone, and the set of - RR types present at the NSEC RR's owner name. The complete set of - NSEC RRs in a zone both indicate which RRsets exist in a zone and - also form a chain of owner names in the zone. This information is - used to provide authenticated denial of existence for DNS data, as - described in RFC 2535 [3]. - - The type value for the NSEC RR is 47. - - - - -Schlyter Expires September 9, 2004 [Page 3] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - - The NSEC RR RDATA format is class independent and defined for all - classes. - - The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL - field. This is in the spirit of negative caching [2]. - -2.1 NSEC RDATA Wire Format - - The RDATA of the NSEC RR is as shown below: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / Next Domain Name / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / List of Type Bit Map(s) / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -2.1.1 The Next Domain Name Field - - The Next Domain Name field contains the owner name of the next RR in - the canonical ordering of the zone. The value of the Next Domain - Name field in the last NSEC record in the zone is the name of the - zone apex (the owner name of the zone's SOA RR). - - A sender MUST NOT use DNS name compression on the Next Domain Name - field when transmitting an NSEC RR. A receiver which receives an - NSEC RR containing a compressed Next Domain Name field SHOULD - decompress the field value. - - Owner names of RRsets not authoritative for the given zone (such as - glue records) MUST NOT be listed in the Next Domain Name unless at - least one authoritative RRset exists at the same owner name. - -2.1.2 The List of Type Bit Map(s) Field - - The RR type space is split into 256 window blocks, each representing - the low-order 8 bits of the 16-bit RR type space. Each block that has - at least one active RR type is encoded using a single octet window - number (from 0 to 255), a single octet bitmap length (from 1 to 32) - indicating the number of octets used for the window block's bitmap, - and up to 32 octets (256 bits) of bitmap. - - Blocks are present in the NSEC RR RDATA in increasing numerical - order. - - "|" denotes concatenation - - - -Schlyter Expires September 9, 2004 [Page 4] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - - Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + - - Each bitmap encodes the low-order 8 bits of RR types within the - window block, in network bit order. The first bit is bit 0. For - window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds - to RR type 2 (NS), and so forth. For window block 1, bit 1 - corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to - 1, it indicates that an RRset of that type is present for the NSEC - RR's owner name. If a bit is set to 0, it indicates that no RRset of - that type is present for the NSEC RR's owner name. - - Since bit 0 in window block 0 refers to the non-existing RR type 0, - it MUST be set to 0. After verification, the validator MUST ignore - the value of bit 0 in window block 0. - - Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4] - (section 3.1) or within the range reserved for assignment only to - QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in - zone data. If encountered, they must be ignored upon reading. - - Blocks with no types present MUST NOT be included. Trailing zero - octets in the bitmap MUST be omitted. The length of each block's - bitmap is determined by the type code with the largest numerical - value, within that block, among the set of RR types present at the - NSEC RR's owner name. Trailing zero octets not specified MUST be - interpretted as zero octets. - -2.1.3 Inclusion of Wildcard Names in NSEC RDATA - - If a wildcard owner name appears in a zone, the wildcard label ("*") - is treated as a literal symbol and is treated the same as any other - owner name for purposes of generating NSEC RRs. Wildcard owner names - appear in the Next Domain Name field without any wildcard expansion. - RFC 2535 [3] describes the impact of wildcards on authenticated - denial of existence. - -2.2 The NSEC RR Presentation Format - - The presentation format of the RDATA portion is as follows: - - The Next Domain Name field is represented as a domain name. - - The List of Type Bit Map(s) Field is represented as a sequence of RR - type mnemonics. When the mnemonic is not known, the TYPE - representation as described in RFC 3597 [5] (section 5) MUST be used. - - - - - - -Schlyter Expires September 9, 2004 [Page 5] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - -2.3 NSEC RR Example - - The following NSEC RR identifies the RRsets associated with - alfa.example.com. and identifies the next authoritative name after - alfa.example.com. - - alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234 - - The first four text fields specify the name, TTL, Class, and RR type - (NSEC). The entry host.example.com. is the next authoritative name - after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC - and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and - TYPE1234 RRsets associated with the name alfa.example.com. - - The RDATA section of the NSEC RR above would be encoded as: - - 0x04 'h' 'o' 's' 't' - 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e' - 0x03 'c' 'o' 'm' 0x00 - 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03 - 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 - 0x00 0x00 0x00 0x00 0x20 - - Assuming that the resolver can authenticate this NSEC record, it - could be used to prove that beta.example.com does not exist, or could - be used to prove there is no AAAA record associated with - alfa.example.com. Authenticated denial of existence is discussed in - RFC 2535 [3]. - -3. IANA Considerations - - This document introduces no new IANA considerations, because all of - the protocol parameters used in this document have already been - assigned by RFC TCR [6]. - -4. Security Considerations - - The update of the RDATA format and encoding does not affect the - security of the use of NSEC RRs. - -Normative References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [2] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC - - - -Schlyter Expires September 9, 2004 [Page 6] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - - 2308, March 1998. - - [3] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [4] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name - System (DNS) IANA Considerations", BCP 42, RFC 2929, September - 2000. - - [5] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) - Types", RFC 3597, September 2003. - - [6] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work - in progress), October 2003. - -Informational References - - [7] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [8] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - -Author's Address - - Jakob Schlyter (editor) - Karl Gustavsgatan 15 - Goteborg SE-411 25 - Sweden - - EMail: jakob@schlyter.se - -Appendix A. Acknowledgements - - The encoding described in this document was initially proposed by - Mark Andrews. Other encodings where proposed by David Blacka and - Michael Graff. - - - - - - - - - - - - -Schlyter Expires September 9, 2004 [Page 7] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances of - licenses to be made available, or the result of an attempt made to - obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification can - be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - -Full Copyright Statement - - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assignees. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - - - -Schlyter Expires September 9, 2004 [Page 8] - -Internet-Draft DNSSEC NSEC RDATA Format March 2004 - - - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Schlyter Expires September 9, 2004 [Page 9] - diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt deleted file mode 100644 index 04addcfb24..0000000000 --- a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-00.txt +++ /dev/null @@ -1,1288 +0,0 @@ - - -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] -