From 8a5837001ae05489b527bd095cae992338f3242a Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 16 Feb 2004 22:34:51 +0000 Subject: [PATCH 1/5] new draft --- ...-ietf-dnsop-ohta-shared-root-server-03.txt | 279 ++++++++++++++++++ 1 file changed, 279 insertions(+) create mode 100644 doc/draft/draft-ietf-dnsop-ohta-shared-root-server-03.txt diff --git a/doc/draft/draft-ietf-dnsop-ohta-shared-root-server-03.txt b/doc/draft/draft-ietf-dnsop-ohta-shared-root-server-03.txt new file mode 100644 index 0000000000..fb08c89b47 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ohta-shared-root-server-03.txt @@ -0,0 +1,279 @@ + +INTERNET DRAFT M. Ohta +draft-ietf-dnsop-ohta-shared-root-server-03.txt + Tokyo Institute of Technology + February 2004 + + Root Name Servers with Inter Domain Anycast Addresses + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + +Abstract + + This memo describes an operational guideline for millions of name + servers to share an interdomain anycast address. + + It enables people operate as many root name servers as they want and + still make them traceable. + +1. Motivation + + DNS root servers are the essential component of the Internet that all + the ISPs in the world want to run several root servers. + + To satisfy them, we need to have thousands or millions of root + servers. + + However, because of the restriction on DNS message size over UDP, the + number of unicast IP addresses of root servers is severely limited. + + Thus, it is necessary to increase the number of root servers by + + + +M. Ohta Expires on August 14, 2004 [Page 1] + +INTERNET DRAFT Anycast Root Name Servers February 2004 + + + assigning an IP address to a lot of root servers. + + Even if DNS were designed to allow a lot of root servers, it is + difficult for DNS clients to choose the best (with regard to + availability, credibility of zone content, delay, domain policy etc.) + root servers among so many root servers. It is not practical to ping + millions of servers to find which has the smallest RTT. + + This memo proposes a mechanism of policy based selection of a root + server sharing an IP address (anycast IP address) with other root + servers and discusses operational issues related to it. + + Because the selection is policy based, domain administrators have + some control over the selection of the best root server among root + servers sharing an IP address. + + Note that operations similar to that described in this memo are + possible today locally without global coordination by any operator + who may be irritated by the lack of his control on (sufficiently + many) root servers, which may be a source of some operational + problems. This memo is an attempt to document the way to solve the + problem in a least harmful manner. + + Similar operation described in this memo may be applicable to gTLD or + other global servers but it is outside the scope of this memo. + +2. Suggested Operation + + As is demonstrated by proliferated private use addresses, it is easy + to set up routers to let unicast addresses have local scopes. It is + also easy to let the unicast addresses have nested local scopes. The + important difference between the addresses for private use and root + servers is in their semantics that the root servers sharing an + address also share the globally unique semantics of the address. The + root servers may share a globally unique DNS host name, too. + + A possible problem of such addresses is that the shared addresses can + not be used for global communication. + + So, the root name servers with the anycast addresses must have + additional globally unique unicast address (or addresses), which may + be used for global communication such as zone transfer. + + The other possible problem of such addresses is that the shared + addresses are not managed by a single entity that the mapping from + the shared address of a root server to some operational entity is + impossible. + + + + +M. Ohta Expires on August 14, 2004 [Page 2] + +INTERNET DRAFT Anycast Root Name Servers February 2004 + + + However, if a router adjacent to (or near) the root server has a + globally unique address, it is possible to map from the global + address to an operational entity, which is expected to be operating + the root server. That is, tools like "traceroute" work to uniquely + identify the operational entity of the root servers sharing a anycast + address. + + To be compatible with the current practice that a single address + belong to a single AS, each anycast address is assigned its own AS + number. There will be multiple ASes of the AS number containing the + same address ranges. + + ASes, still, can be identified by adjacent ASes. For example, + network operators may choose their favorite root server based on the + AS numbers of the next hop ASes with, for example, AS path and BGP + policy. + + It is required that operators of an AS adjacent to the root servers' + AS be fully responsible to the operation of the root servers. If a + root server's AS is adjacent to multiple ASes, operators of all the + ASes must be fully responsible to the operation of the root server. + Thus, if there is a routing problem related to a root server, + operators of the next hop AS(es) should be contacted. + + To avoid complex routing tricks, globally unique unicast address(es) + of the root name servers must be taken from the AS(es) adjacent to + the root server's AS. Then, in a likely simple case that the root + server's AS consists of a single host, which acts as a name server + and a BGP router, the host should peer with adjacent AS(es) through + an interface(s) address(es) of which belongs to the adjacent AS(es). + If the root server's AS has more complex structure, special IGP + arrangement of globally unique unicast address(es) is necessary in + the AS and at the border router(s) of the adjacent AS(es). The border + router(s) must accept IGP information advertised from the root + server's AS. + +3. Redundancy Considerations + + There is widespread misunderstanding on anycast (and multicast) in, + including but not limited to, RFC1546 and RFC2461 that anycast (and + multicast) could have provided meaningful redundancy or fault + tolerance. + + It is true that anycast and multicast tolerate some route faults. + + However, a fault mode where a server process crash on an anycast + server a route to which is still alive, can not be tolerated. + + + + +M. Ohta Expires on August 14, 2004 [Page 3] + +INTERNET DRAFT Anycast Root Name Servers February 2004 + + + Multicast, at least scalable one, is no better, because scalable + multicast needs some multicast server, such as a rendez vous point or + a core, which is the single point of failure. + + Redundancy with no single point of failure can only be provided by + using multiple anycast (or multicast) addresses served by different + anycast (or multicast) servers. + + Thus, it is meaningless that RFC1546 considers a case where there are + multiple anycast servers on a single subnet, because of redundancy. + Like unicast, it is a configuration error if there are two or more + anycast servers sharing an anycast address in a subnet, which means + that anycast works with IPv4 ARP and no special treatment of ND in + RFC2461 is necessary. + +4. Assignment + + As is discussed in the previous section, when a server with an + anycast address fails but a route to it is still available, there is + no way for clients use other servers with the same anycast address. + That is, anycast does not improve availability of servers so much. + + So, even with anycast addresses, there should be multiple root + servers. + + However, as anycast solves the problem of load concentration, we + don't need so many anycast IP addresses, + + We should have at least 3 and at most 7 anycast addresses for root + servers. + +5. Security Considerations + + This memo describes just an operational guideline with no protocol + change. As such, the guideline does not introduce any security issues + of the protocol level. + + As the route forgery to the root servers can be implemented today + without this memo by anyone including local intruders, the guideline + does not introduce any security issues of the operational level, + either. + + A guideline to track down and verify a route or an AS path to a valid + or a forged root server is described in section 2. + + Furthermore, if an ISP or a site operate its own anycast root server, + hosts of the ISP or the site using the root server is protected from + external forged route. + + + +M. Ohta Expires on August 14, 2004 [Page 4] + +INTERNET DRAFT Anycast Root Name Servers February 2004 + + + In addition, if a lot of local root servers share an anycast address, + it reduce the effect of distributed denial of service attack on the + anycast address. + +6. Author's Address + + Masataka Ohta + Graduate School of Information Science and Engineering + Tokyo Institute of Technology + 2-12-1, O-okayama, Meguro-ku + Tokyo 152-8552, JAPAN + + Phone: +81-3-5734-3299 + Fax: +81-3-5734-3299 + EMail: mohta@necom830.hpcl.titech.ac.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +M. Ohta Expires on August 14, 2004 [Page 5] + + From d9b30d6dc0f1171df9d2eb23f5193745ba9c37b8 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 16 Feb 2004 23:01:46 +0000 Subject: [PATCH 2/5] remove --- ...-ietf-dnsop-ohta-shared-root-server-03.txt | 279 ------------------ 1 file changed, 279 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsop-ohta-shared-root-server-03.txt diff --git a/doc/draft/draft-ietf-dnsop-ohta-shared-root-server-03.txt b/doc/draft/draft-ietf-dnsop-ohta-shared-root-server-03.txt deleted file mode 100644 index fb08c89b47..0000000000 --- a/doc/draft/draft-ietf-dnsop-ohta-shared-root-server-03.txt +++ /dev/null @@ -1,279 +0,0 @@ - -INTERNET DRAFT M. Ohta -draft-ietf-dnsop-ohta-shared-root-server-03.txt - Tokyo Institute of Technology - February 2004 - - Root Name Servers with Inter Domain Anycast Addresses - -Status of this Memo - - This document is an Internet-Draft and is subject to all provisions - of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - -Abstract - - This memo describes an operational guideline for millions of name - servers to share an interdomain anycast address. - - It enables people operate as many root name servers as they want and - still make them traceable. - -1. Motivation - - DNS root servers are the essential component of the Internet that all - the ISPs in the world want to run several root servers. - - To satisfy them, we need to have thousands or millions of root - servers. - - However, because of the restriction on DNS message size over UDP, the - number of unicast IP addresses of root servers is severely limited. - - Thus, it is necessary to increase the number of root servers by - - - -M. Ohta Expires on August 14, 2004 [Page 1] - -INTERNET DRAFT Anycast Root Name Servers February 2004 - - - assigning an IP address to a lot of root servers. - - Even if DNS were designed to allow a lot of root servers, it is - difficult for DNS clients to choose the best (with regard to - availability, credibility of zone content, delay, domain policy etc.) - root servers among so many root servers. It is not practical to ping - millions of servers to find which has the smallest RTT. - - This memo proposes a mechanism of policy based selection of a root - server sharing an IP address (anycast IP address) with other root - servers and discusses operational issues related to it. - - Because the selection is policy based, domain administrators have - some control over the selection of the best root server among root - servers sharing an IP address. - - Note that operations similar to that described in this memo are - possible today locally without global coordination by any operator - who may be irritated by the lack of his control on (sufficiently - many) root servers, which may be a source of some operational - problems. This memo is an attempt to document the way to solve the - problem in a least harmful manner. - - Similar operation described in this memo may be applicable to gTLD or - other global servers but it is outside the scope of this memo. - -2. Suggested Operation - - As is demonstrated by proliferated private use addresses, it is easy - to set up routers to let unicast addresses have local scopes. It is - also easy to let the unicast addresses have nested local scopes. The - important difference between the addresses for private use and root - servers is in their semantics that the root servers sharing an - address also share the globally unique semantics of the address. The - root servers may share a globally unique DNS host name, too. - - A possible problem of such addresses is that the shared addresses can - not be used for global communication. - - So, the root name servers with the anycast addresses must have - additional globally unique unicast address (or addresses), which may - be used for global communication such as zone transfer. - - The other possible problem of such addresses is that the shared - addresses are not managed by a single entity that the mapping from - the shared address of a root server to some operational entity is - impossible. - - - - -M. Ohta Expires on August 14, 2004 [Page 2] - -INTERNET DRAFT Anycast Root Name Servers February 2004 - - - However, if a router adjacent to (or near) the root server has a - globally unique address, it is possible to map from the global - address to an operational entity, which is expected to be operating - the root server. That is, tools like "traceroute" work to uniquely - identify the operational entity of the root servers sharing a anycast - address. - - To be compatible with the current practice that a single address - belong to a single AS, each anycast address is assigned its own AS - number. There will be multiple ASes of the AS number containing the - same address ranges. - - ASes, still, can be identified by adjacent ASes. For example, - network operators may choose their favorite root server based on the - AS numbers of the next hop ASes with, for example, AS path and BGP - policy. - - It is required that operators of an AS adjacent to the root servers' - AS be fully responsible to the operation of the root servers. If a - root server's AS is adjacent to multiple ASes, operators of all the - ASes must be fully responsible to the operation of the root server. - Thus, if there is a routing problem related to a root server, - operators of the next hop AS(es) should be contacted. - - To avoid complex routing tricks, globally unique unicast address(es) - of the root name servers must be taken from the AS(es) adjacent to - the root server's AS. Then, in a likely simple case that the root - server's AS consists of a single host, which acts as a name server - and a BGP router, the host should peer with adjacent AS(es) through - an interface(s) address(es) of which belongs to the adjacent AS(es). - If the root server's AS has more complex structure, special IGP - arrangement of globally unique unicast address(es) is necessary in - the AS and at the border router(s) of the adjacent AS(es). The border - router(s) must accept IGP information advertised from the root - server's AS. - -3. Redundancy Considerations - - There is widespread misunderstanding on anycast (and multicast) in, - including but not limited to, RFC1546 and RFC2461 that anycast (and - multicast) could have provided meaningful redundancy or fault - tolerance. - - It is true that anycast and multicast tolerate some route faults. - - However, a fault mode where a server process crash on an anycast - server a route to which is still alive, can not be tolerated. - - - - -M. Ohta Expires on August 14, 2004 [Page 3] - -INTERNET DRAFT Anycast Root Name Servers February 2004 - - - Multicast, at least scalable one, is no better, because scalable - multicast needs some multicast server, such as a rendez vous point or - a core, which is the single point of failure. - - Redundancy with no single point of failure can only be provided by - using multiple anycast (or multicast) addresses served by different - anycast (or multicast) servers. - - Thus, it is meaningless that RFC1546 considers a case where there are - multiple anycast servers on a single subnet, because of redundancy. - Like unicast, it is a configuration error if there are two or more - anycast servers sharing an anycast address in a subnet, which means - that anycast works with IPv4 ARP and no special treatment of ND in - RFC2461 is necessary. - -4. Assignment - - As is discussed in the previous section, when a server with an - anycast address fails but a route to it is still available, there is - no way for clients use other servers with the same anycast address. - That is, anycast does not improve availability of servers so much. - - So, even with anycast addresses, there should be multiple root - servers. - - However, as anycast solves the problem of load concentration, we - don't need so many anycast IP addresses, - - We should have at least 3 and at most 7 anycast addresses for root - servers. - -5. Security Considerations - - This memo describes just an operational guideline with no protocol - change. As such, the guideline does not introduce any security issues - of the protocol level. - - As the route forgery to the root servers can be implemented today - without this memo by anyone including local intruders, the guideline - does not introduce any security issues of the operational level, - either. - - A guideline to track down and verify a route or an AS path to a valid - or a forged root server is described in section 2. - - Furthermore, if an ISP or a site operate its own anycast root server, - hosts of the ISP or the site using the root server is protected from - external forged route. - - - -M. Ohta Expires on August 14, 2004 [Page 4] - -INTERNET DRAFT Anycast Root Name Servers February 2004 - - - In addition, if a lot of local root servers share an anycast address, - it reduce the effect of distributed denial of service attack on the - anycast address. - -6. Author's Address - - Masataka Ohta - Graduate School of Information Science and Engineering - Tokyo Institute of Technology - 2-12-1, O-okayama, Meguro-ku - Tokyo 152-8552, JAPAN - - Phone: +81-3-5734-3299 - Fax: +81-3-5734-3299 - EMail: mohta@necom830.hpcl.titech.ac.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -M. Ohta Expires on August 14, 2004 [Page 5] - - From 4230c2e85e44b1cf6e7ec17a695a8581b9a09940 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 17 Feb 2004 03:34:55 +0000 Subject: [PATCH 3/5] lookup RRSIG (46) not SIG (24) in getrrsetbyname test. --- bin/tests/system/lwresd/lwtest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bin/tests/system/lwresd/lwtest.c b/bin/tests/system/lwresd/lwtest.c index 602b09687a..fc3d4871d7 100644 --- a/bin/tests/system/lwresd/lwtest.c +++ b/bin/tests/system/lwresd/lwtest.c @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: lwtest.c,v 1.24 2002/08/27 04:53:39 marka Exp $ */ +/* $Id: lwtest.c,v 1.25 2004/02/17 03:34:55 marka Exp $ */ #include @@ -761,7 +761,7 @@ main(void) { test_getrrsetbyname("a.example1.", 1, 1, 1, 0, 1); test_getrrsetbyname("e.example1.", 1, 1, 1, 1, 1); test_getrrsetbyname("e.example1.", 1, 255, 1, 1, 0); - test_getrrsetbyname("e.example1.", 1, 24, 1, 0, 1); + test_getrrsetbyname("e.example1.", 1, 46, 1, 0, 1); test_getrrsetbyname("", 1, 1, 0, 0, 0); if (fails == 0) From 89783da064f4f9bf2e82d2b3941ddeffe2a8c30d Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 17 Feb 2004 03:40:23 +0000 Subject: [PATCH 4/5] 1581. [func] Disable DNSSEC support by default. To enable DNSSEC specify "enable-dnssec yes;" in named.conf. --- CHANGES | 3 +++ bin/named/config.c | 3 ++- bin/named/query.c | 13 +++++++++++-- bin/named/server.c | 14 ++++++++++---- bin/tests/system/dnssec/ns1/named.conf | 3 ++- bin/tests/system/dnssec/ns2/named.conf | 3 ++- bin/tests/system/dnssec/ns3/named.conf | 3 ++- bin/tests/system/dnssec/ns4/named.conf | 3 ++- bin/tests/system/dnssec/ns5/named.conf | 3 ++- bin/tests/system/dnssec/ns6/named.conf | 3 ++- bin/tests/system/lwresd/ns1/named.conf | 3 ++- doc/arm/Bv9ARM-book.xml | 11 ++++++++++- lib/dns/include/dns/view.h | 3 ++- lib/dns/view.c | 3 ++- lib/isccfg/namedconf.c | 3 ++- 15 files changed, 56 insertions(+), 18 deletions(-) diff --git a/CHANGES b/CHANGES index 9eccc846e9..7183d3c9a4 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,6 @@ +1581. [func] Disable DNSSEC support by default. To enable + DNSSEC specify "enable-dnssec yes;" in named.conf. + 1580. [placeholder] rt3746a 1579. [placeholder] rt3746a diff --git a/bin/named/config.c b/bin/named/config.c index 4df6150861..6ef209a424 100644 --- a/bin/named/config.c +++ b/bin/named/config.c @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: config.c,v 1.42 2003/04/17 12:11:39 marka Exp $ */ +/* $Id: config.c,v 1.43 2004/02/17 03:40:19 marka Exp $ */ #include @@ -123,6 +123,7 @@ options {\n\ check-names master ignore;\n\ check-names slave ignore;\n\ check-names response ignore;\n\ + enable-dnssec no; /* Make yes for 9.4. */ \n\ \n\ /* zone */\n\ allow-query {any;};\n\ diff --git a/bin/named/query.c b/bin/named/query.c index c571b271c9..838af2ec90 100644 --- a/bin/named/query.c +++ b/bin/named/query.c @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: query.c,v 1.253 2004/02/03 00:59:03 marka Exp $ */ +/* $Id: query.c,v 1.254 2004/02/17 03:40:20 marka Exp $ */ #include @@ -3342,6 +3342,14 @@ ns_query_start(ns_client_t *client) { */ client->next = query_next_callback; + /* + * Behave as if we don't support DNSSEC if not enabled. + */ + if (!client->view->enablednssec) { + message->flags &= ~DNS_MESSAGEFLAG_CD; + client->extflags &= ~DNS_MESSAGEEXTFLAG_DO; + } + if ((message->flags & DNS_MESSAGEFLAG_RD) != 0) client->query.attributes |= NS_QUERYATTR_WANTRECURSION; @@ -3477,7 +3485,8 @@ ns_query_start(ns_client_t *client) { * Set AD. We must clear it if we add non-validated data to a * response. */ - message->flags |= DNS_MESSAGEFLAG_AD; + if (client->view->enablednssec) + message->flags |= DNS_MESSAGEFLAG_AD; qclient = NULL; ns_client_attach(client, &qclient); diff --git a/bin/named/server.c b/bin/named/server.c index ebb1076eec..d55bd9866d 100644 --- a/bin/named/server.c +++ b/bin/named/server.c @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: server.c,v 1.411 2004/01/27 02:13:22 marka Exp $ */ +/* $Id: server.c,v 1.412 2004/02/17 03:40:20 marka Exp $ */ #include @@ -1061,13 +1061,19 @@ configure_view(dns_view_t *view, cfg_obj_t *config, cfg_obj_t *vconfig, result = ns_config_get(maps, "provide-ixfr", &obj); INSIST(result == ISC_R_SUCCESS); view->provideixfr = cfg_obj_asboolean(obj); + + obj = NULL; + result = ns_config_get(maps, "enable-dnssec", &obj); + INSIST(result == ISC_R_SUCCESS); + view->enablednssec = cfg_obj_asboolean(obj); /* * For now, there is only one kind of trusted keys, the * "security roots". */ - CHECK(configure_view_dnsseckeys(vconfig, config, mctx, - &view->secroots)); + if (view->enablednssec) + CHECK(configure_view_dnsseckeys(vconfig, config, mctx, + &view->secroots)); obj = NULL; result = ns_config_get(maps, "max-cache-ttl", &obj); @@ -1122,7 +1128,7 @@ configure_view(dns_view_t *view, cfg_obj_t *config, cfg_obj_t *vconfig, } } else dns_view_setrootdelonly(view, ISC_FALSE); - + result = ISC_R_SUCCESS; cleanup: diff --git a/bin/tests/system/dnssec/ns1/named.conf b/bin/tests/system/dnssec/ns1/named.conf index 02efa28580..463fb77bb7 100644 --- a/bin/tests/system/dnssec/ns1/named.conf +++ b/bin/tests/system/dnssec/ns1/named.conf @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.16 2001/01/09 21:42:47 bwelling Exp $ */ +/* $Id: named.conf,v 1.17 2004/02/17 03:40:20 marka Exp $ */ // NS1 @@ -29,6 +29,7 @@ options { listen-on-v6 { none; }; recursion no; notify yes; + enable-dnssec yes; }; zone "." { diff --git a/bin/tests/system/dnssec/ns2/named.conf b/bin/tests/system/dnssec/ns2/named.conf index 8b7d80a436..6f464e6c2c 100644 --- a/bin/tests/system/dnssec/ns2/named.conf +++ b/bin/tests/system/dnssec/ns2/named.conf @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.19 2002/02/20 03:33:54 marka Exp $ */ +/* $Id: named.conf,v 1.20 2004/02/17 03:40:21 marka Exp $ */ // NS2 @@ -29,6 +29,7 @@ options { listen-on-v6 { none; }; recursion no; notify yes; + enable-dnssec yes; }; zone "." { diff --git a/bin/tests/system/dnssec/ns3/named.conf b/bin/tests/system/dnssec/ns3/named.conf index 2fbcb17a4c..5deba648ec 100644 --- a/bin/tests/system/dnssec/ns3/named.conf +++ b/bin/tests/system/dnssec/ns3/named.conf @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.21 2002/02/20 03:33:58 marka Exp $ */ +/* $Id: named.conf,v 1.22 2004/02/17 03:40:21 marka Exp $ */ // NS3 @@ -29,6 +29,7 @@ options { listen-on-v6 { none; }; recursion no; notify yes; + enable-dnssec yes; }; zone "." { diff --git a/bin/tests/system/dnssec/ns4/named.conf b/bin/tests/system/dnssec/ns4/named.conf index c0b0d5a66a..2f3a7e331b 100644 --- a/bin/tests/system/dnssec/ns4/named.conf +++ b/bin/tests/system/dnssec/ns4/named.conf @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.18 2001/01/11 20:41:37 gson Exp $ */ +/* $Id: named.conf,v 1.19 2004/02/17 03:40:21 marka Exp $ */ // NS4 @@ -28,6 +28,7 @@ options { listen-on { 10.53.0.4; }; listen-on-v6 { none; }; recursion yes; + enable-dnssec yes; }; zone "." { diff --git a/bin/tests/system/dnssec/ns5/named.conf b/bin/tests/system/dnssec/ns5/named.conf index a0abc3b8a7..b068b895c4 100644 --- a/bin/tests/system/dnssec/ns5/named.conf +++ b/bin/tests/system/dnssec/ns5/named.conf @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.16 2001/01/11 20:41:39 gson Exp $ */ +/* $Id: named.conf,v 1.17 2004/02/17 03:40:21 marka Exp $ */ // NS5 @@ -28,6 +28,7 @@ options { listen-on { 10.53.0.5; }; listen-on-v6 { none; }; recursion yes; + enable-dnssec yes; }; zone "." { diff --git a/bin/tests/system/dnssec/ns6/named.conf b/bin/tests/system/dnssec/ns6/named.conf index 53087c0955..b1b8fb858d 100644 --- a/bin/tests/system/dnssec/ns6/named.conf +++ b/bin/tests/system/dnssec/ns6/named.conf @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.2 2004/01/15 04:09:17 marka Exp $ */ +/* $Id: named.conf,v 1.3 2004/02/17 03:40:22 marka Exp $ */ // NS6 @@ -30,6 +30,7 @@ options { recursion yes; notify yes; disable-algorithms . { DSA; }; + enable-dnssec yes; }; zone "." { diff --git a/bin/tests/system/lwresd/ns1/named.conf b/bin/tests/system/lwresd/ns1/named.conf index f9c5b9d8dc..f35a313c5a 100644 --- a/bin/tests/system/lwresd/ns1/named.conf +++ b/bin/tests/system/lwresd/ns1/named.conf @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: named.conf,v 1.11 2001/01/09 21:43:45 bwelling Exp $ */ +/* $Id: named.conf,v 1.12 2004/02/17 03:40:22 marka Exp $ */ options { query-source address 10.53.0.1; @@ -27,6 +27,7 @@ options { listen-on-v6 { none; }; recursion no; notify no; + enable-dnssec yes; }; zone "." { diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index 419272fa02..afa2063eb7 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ - + BIND 9 Administrator Reference Manual @@ -2744,6 +2744,7 @@ statement in the named.conf file: rfc2308-type1 yes_or_no; use-id-pool yes_or_no; maintain-ixfr-base yes_or_no; + enable-dnssec yes_or_no; forward ( only | first ); forwarders { ip_addr port ip_port ; ip_addr port ip_port ; ... }; dual-stack-servers port ip_port { ( domain_name port ip_port | ip_addr port ip_port ) ; ... }; @@ -3324,6 +3325,14 @@ when the serial number on the master is less than what named currently has. The default is no. +enable-dnssec + + +Enable DNSSEC support in named. Unless set to yes +named behaves as if it does not support DNSSEC. +The default is no. + + diff --git a/lib/dns/include/dns/view.h b/lib/dns/include/dns/view.h index 6ef9b03669..e1dae7f1eb 100644 --- a/lib/dns/include/dns/view.h +++ b/lib/dns/include/dns/view.h @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: view.h,v 1.87 2003/09/30 05:56:17 marka Exp $ */ +/* $Id: view.h,v 1.88 2004/02/17 03:40:23 marka Exp $ */ #ifndef DNS_VIEW_H #define DNS_VIEW_H 1 @@ -107,6 +107,7 @@ struct dns_view { isc_boolean_t additionalfromcache; isc_boolean_t additionalfromauth; isc_boolean_t minimalresponses; + isc_boolean_t enablednssec; dns_transfer_format_t transfer_format; dns_acl_t * queryacl; dns_acl_t * recursionacl; diff --git a/lib/dns/view.c b/lib/dns/view.c index 11e61bfcab..7004e3cbf3 100644 --- a/lib/dns/view.c +++ b/lib/dns/view.c @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: view.c,v 1.123 2003/10/03 02:19:31 marka Exp $ */ +/* $Id: view.c,v 1.124 2004/02/17 03:40:23 marka Exp $ */ #include @@ -155,6 +155,7 @@ dns_view_create(isc_mem_t *mctx, dns_rdataclass_t rdclass, view->auth_nxdomain = ISC_FALSE; /* Was true in BIND 8 */ view->additionalfromcache = ISC_TRUE; view->additionalfromauth = ISC_TRUE; + view->enablednssec = ISC_TRUE; view->minimalresponses = ISC_FALSE; view->transfer_format = dns_one_answer; view->queryacl = NULL; diff --git a/lib/isccfg/namedconf.c b/lib/isccfg/namedconf.c index e9bb2f14b6..7f105cac5b 100644 --- a/lib/isccfg/namedconf.c +++ b/lib/isccfg/namedconf.c @@ -15,7 +15,7 @@ * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ -/* $Id: namedconf.c,v 1.25 2004/01/14 02:06:51 marka Exp $ */ +/* $Id: namedconf.c,v 1.26 2004/02/17 03:40:23 marka Exp $ */ #include @@ -678,6 +678,7 @@ view_clauses[] = { { "root-delegation-only", &cfg_type_optional_exclude, 0 }, { "disable-algorithms", &cfg_type_disablealgorithm, CFG_CLAUSEFLAG_MULTI }, + { "enable-dnssec", &cfg_type_boolean, 0 }, { NULL, NULL, 0 } }; From 6c09e435c8f1b4649cd3262ced72c48c570d8ccb Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 17 Feb 2004 22:34:54 +0000 Subject: [PATCH 5/5] new draft --- ... draft-ietf-dnsext-dnssec-protocol-05.txt} | 1046 +++++++++-------- ...> draft-ietf-dnsext-dnssec-records-07.txt} | 430 +++---- 2 files changed, 766 insertions(+), 710 deletions(-) rename doc/draft/{draft-ietf-dnsext-dnssec-protocol-04.txt => draft-ietf-dnsext-dnssec-protocol-05.txt} (82%) rename doc/draft/{draft-ietf-dnsext-dnssec-records-06.txt => draft-ietf-dnsext-dnssec-records-07.txt} (86%) diff --git a/doc/draft/draft-ietf-dnsext-dnssec-protocol-04.txt b/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt similarity index 82% rename from doc/draft/draft-ietf-dnsext-dnssec-protocol-04.txt rename to doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt index 24f94a7efc..1a9f8aaf7a 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-protocol-04.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-protocol-05.txt @@ -2,7 +2,7 @@ DNS Extensions R. Arends Internet-Draft Telematica Instituut -Expires: June 16, 2004 M. Larson +Expires: August 16, 2004 M. Larson VeriSign R. Austein ISC @@ -10,11 +10,11 @@ Expires: June 16, 2004 M. Larson USC/ISI S. Rose NIST - December 17, 2003 + February 16, 2004 Protocol Modifications for the DNS Security Extensions - draft-ietf-dnsext-dnssec-protocol-04 + draft-ietf-dnsext-dnssec-protocol-05 Status of this Memo @@ -36,11 +36,11 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 16, 2004. + This Internet-Draft will expire on August 16, 2004. Copyright Notice - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract @@ -52,9 +52,9 @@ Abstract -Arends, et al. Expires June 16, 2004 [Page 1] +Arends, et al. Expires August 16, 2004 [Page 1] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 defines the concept of a signed zone, along with the requirements for @@ -90,67 +90,68 @@ Table of Contents 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 . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.2.1 The DO bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.2 The CD bit . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 3.2.3 The AD bit . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 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 . . . . . . . . . . . . . . . . . 21 - 4.5 Response Caching . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 22 - 4.8 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 23 - 4.8.1 ENDS Support . . . . . . . . . . . . . . . . . . . . . . . . 23 - 4.8.2 Handling of the CD and AD Bits . . . . . . . . . . . . . . . 23 + 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 June 16, 2004 [Page 2] +Arends, et al. Expires August 16, 2004 [Page 2] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 - 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25 - 5.1 Special Considerations for Islands of Security . . . . . . . 26 - 5.2 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26 - 5.3 Authenticating an RRset Using an RRSIG RR . . . . . . . . . 27 - 5.3.1 Checking the RRSIG RR Validity . . . . . . . . . . . . . . . 28 - 5.3.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 29 - 5.3.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30 + 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 5.4 Authenticated Denial of Existence . . . . . . . . . . . . . 31 - 5.5 Authentication Example . . . . . . . . . . . . . . . . . . . 32 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33 - 7. Security Considerations . . . . . . . . . . . . . . . . . . 34 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 - Normative References . . . . . . . . . . . . . . . . . . . . 36 - Informative References . . . . . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 - A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . 39 - B. Example Responses . . . . . . . . . . . . . . . . . . . . . 45 - B.1 Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 - B.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 46 - B.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 47 - B.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 48 - B.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 49 - B.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 49 - B.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 50 - B.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 51 - C. Authentication Examples . . . . . . . . . . . . . . . . . . 53 - C.1 Authenticating An Answer . . . . . . . . . . . . . . . . . . 53 - C.1.1 Authenticating the example DNSKEY RR . . . . . . . . . . . . 53 - C.2 Name Error . . . . . . . . . . . . . . . . . . . . . . . . . 54 - C.3 No Data Error . . . . . . . . . . . . . . . . . . . . . . . 54 - C.4 Referral to Signed Zone . . . . . . . . . . . . . . . . . . 54 - C.5 Referral to Unsigned Zone . . . . . . . . . . . . . . . . . 54 - C.6 Wildcard Expansion . . . . . . . . . . . . . . . . . . . . . 55 - C.7 Wildcard No Data Error . . . . . . . . . . . . . . . . . . . 55 - C.8 DS Child Zone No Data Error . . . . . . . . . . . . . . . . 55 - Intellectual Property and Copyright Statements . . . . . . . 56 + 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 @@ -163,10 +164,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 - -Arends, et al. Expires June 16, 2004 [Page 3] +Arends, et al. Expires August 16, 2004 [Page 3] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 1. Introduction @@ -220,9 +220,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 4] +Arends, et al. Expires August 16, 2004 [Page 4] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 1.3.3 Typos and Minor Corrections @@ -276,50 +276,46 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 5] +Arends, et al. Expires August 16, 2004 [Page 5] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 2. Zone Signing - DNSSEC is built around the concept of signed zones. A signed zone + 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. Any zone which does not include these - records according to the rules in this section MUST be considered - unsigned for the purposes of the DNS security extensions. + 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. Section 2.5 changes the CNAME RR to allow RRSIG and NSEC RRs - to appear at the same owner name as a CNAME RR. + 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 - stored in the zone. A zone key DNSKEY RR has 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. + 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]). This DNSKEY RR SHOULD be either a - zone key or a DNSKEY signing key (see [I-D.ietf-dnsext-dnssec-intro] - for definition). + [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 (which excludes both NS - RRsets at delegation points and glue RRsets), there MUST be at least + 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; @@ -330,18 +326,19 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 o The RRSIG Original TTL field is equal to the TTL of the RRset; - - -Arends, et al. Expires June 16, 2004 [Page 6] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 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 wildcard label if the owner name is a wildcard; + 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 @@ -357,71 +354,73 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 would add no value and would create an infinite loop in the signing process. - The NS RRset which appears at the zone apex name MUST be signed, but - the NS RRsets which appear at delegation points (that is, the NS - RRsets in the parent zone which delegate the name to the child zone's + 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 generated 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. - - The difference between the set of owner names which require RRSIG - records and the set of owner names which 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 - 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. + 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 - - - -Arends, et al. Expires June 16, 2004 [Page 7] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 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 - RRsets at any particular owner name. That is, the signing process - MUST NOT create (or RRSIG) RRs for owner names nodes which were not - the owner name of any RRset before the zone was signed. + 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 non-delegation points nor at a zone's apex. + 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 corresponding NS - RRset. + 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 @@ -431,8 +430,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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. Other types MUST NOT - be present at that name. + 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 @@ -444,9 +444,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 8] +Arends, et al. Expires August 16, 2004 [Page 8] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 2.6 Example of a Secure Zone @@ -500,21 +500,21 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 9] +Arends, et al. Expires August 16, 2004 [Page 9] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 3. Serving - This section describes the behavior of entities which include - security-aware name 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. + 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]. @@ -523,9 +523,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 which receives a DNS query which does - not include the EDNS OPT pseudo-RR or which has the DO bit set to - zero MUST treat the RRSIG, DNSKEY, and NSEC RRs as it would any other + 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 @@ -542,23 +542,23 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 3.1 Authoritative Name Servers - Upon receiving a relevant query which has the EDNS [RFC2671] OPT + 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 which can be used to authenticate a response MUST be + 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 which can be used to provide authenticated denial of + 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 June 16, 2004 [Page 10] +Arends, et al. Expires August 16, 2004 [Page 10] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST @@ -570,16 +570,16 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 3.1.1 Including RRSIG RRs in a Response - When responding to a query which has the DO bit set to one, a + 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 which 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: + 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 - which may need to be included. If space does not permit inclusion + 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 @@ -590,14 +590,14 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 these RRSIG RRs, the name - server MUST NOT set the TC bit solely because these RRSIG RRs - didn't fit. + 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 which has the DO bit set to one and which + 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, @@ -612,38 +612,38 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 11] +Arends, et al. Expires August 16, 2004 [Page 11] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 3.1.3 Including NSEC RRs In a Response - When responding to a query which has the DO bit set to one, a + 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 which exactly match , but does not contain any RRsets which exactly match - . + 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 which match either exactly or via wildcard name expansion. - Wildcard Answer: The zone does not contain any RRsets which exactly - match but does contain an RRset which matches + 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 which exactly - match , does contain one or more RRsets which - matches via wildcard name expansion, but does not - contain any RRsets which match 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 which the name server - is returning is correct given the data which are in the zone. + 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 @@ -668,19 +668,19 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 12] +Arends, et al. Expires August 16, 2004 [Page 12] -Internet-Draft DNSSEC Protocol Modifications December 2003 +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 which would + 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 - which case the name server SHOULD only include the NSEC RR and its + 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 @@ -704,17 +704,17 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 these answer, NSEC and RRSIG RRs, the name + 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 name - 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: + 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 @@ -724,9 +724,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 13] +Arends, et al. Expires August 16, 2004 [Page 13] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 would have been a closer match for . @@ -755,9 +755,10 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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. 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. + 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 @@ -779,16 +780,16 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 - -Arends, et al. Expires June 16, 2004 [Page 14] +Arends, et al. Expires August 16, 2004 [Page 14] -Internet-Draft DNSSEC Protocol Modifications December 2003 +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) along - with the NS RRset. The name server MUST place the NS RRset before - the DS RRset and its associated RRSIG RR(s). + 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 @@ -812,35 +813,39 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 will send queries to the parent zone when - looking for a DS RRset at a delegation point, and thus will never - trigger the corresponding special processing in a security-aware name - server. The rest of this section describes how a security-aware - recursive name server processes a misdirected DS query. + 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: + arises when all the following conditions are met: o the name server has received a query for the DS RRset at a zone - cut; + cut; and - o the name server is authoritative for the child zone; + 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 - - - -Arends, et al. Expires June 16, 2004 [Page 15] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - return either the DS RRset or an error response according to the normal processing rules. @@ -884,19 +889,19 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 - - - -Arends, et al. Expires June 16, 2004 [Page 16] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 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 @@ -916,7 +921,7 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 or + 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 @@ -938,52 +943,34 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 implements the security-aware name server role and the code which implements the security-aware resolver role, respectively. - The resolver side MUST follow the usual rules for caching and - negative caching which would apply to any security-aware resolver. + 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 - - - -Arends, et al. Expires June 16, 2004 [Page 17] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 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 but - MUST NOT strip any DNSSEC RRs that the initiating query explicitly + 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. This is a useful but somewhat - dangerous capability that requires careful handling by security-aware - recursive name servers. + processing of a particular query. - A security-aware recursive name server MUST disregard the CD bit and - perform normal signature validation unless: - - o the name server side received that query via a secure channel; or - - o the recursive name server's local policy dictates that the - recursive name server honor the CD bit even when received via an - insecure channel. - - Discussion of cases in which the CD bit is set to one in the rest of - this section assumes that one or both of the above conditions applies - to the query being processed. If neither condition applies, the - recursive name server MUST process the query as if the CD bit were - set to zero. Note, however, that the name server side MUST always - copy the setting of the CD bit from a query to the corresponding - response, regardless of whether or not the recursive name server - trusts the setting of the CD bit. + 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 @@ -1001,14 +988,6 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 responsibility for performing its own authentication, and the recursive name server should not interfere. - - - -Arends, et al. Expires June 16, 2004 [Page 18] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 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 @@ -1021,7 +1000,15 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 or Authority sections of the response to be + 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 @@ -1060,9 +1047,22 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 19] + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 19] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 4. Resolving @@ -1106,33 +1106,56 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 - - - -Arends, et al. Expires June 16, 2004 [Page 20] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 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 does know the name of the missing NSEC RR, and must - therefore attempt to retrieve it. + 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. - When attempting to retrieve missing NSEC or DS 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. 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 @@ -1146,6 +1169,14 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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. @@ -1160,28 +1191,28 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 4.4 Preconfigured Public Keys A security-aware resolver MUST be capable of being preconfigured with - at least one trusted public key, 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. + 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 - - - -Arends, et al. Expires June 16, 2004 [Page 21] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - + 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, indexed by the triple , with the - 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. + 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 @@ -1192,7 +1223,22 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 on the behavior of security-aware recursive name servers. A security-aware resolver MUST zero the AD bit when composing query - messages. + 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 @@ -1225,14 +1271,6 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 - - - -Arends, et al. Expires June 16, 2004 [Page 22] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 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 @@ -1242,59 +1280,77 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 -4.8.1 ENDS Support - - A security-aware stub resolver MUST include an EDNS [RFC2671] OPT - pseudo-RR with the DO [RFC3225] bit set to one when sending queries. - - A security-aware stub 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 stub - 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. - 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. A security-aware stub resolver MAY include the - DNSSEC RRs returned by a security-aware recursive name server as part - of the data that it the stub resolver hands back to the application - which invoked it but is not required to do so. + contain DNSSEC RRs. -4.8.2 Handling of the CD and AD Bits +4.8.1 Handling of the DO Bit - A security-aware stub resolver SHOULD NOT set the CD bit when sending - queries unless requested by the application layer, since by - definition, a security-aware stub resolver does not validate - signatures and thus depends on the security-aware recursive name - server to perform validation on its behalf. + 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 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 + 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 - - - -Arends, et al. Expires June 16, 2004 [Page 23] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 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. @@ -1340,9 +1396,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 24] +Arends, et al. Expires August 16, 2004 [Page 25] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 5. Authenticating DNS Responses @@ -1362,10 +1418,10 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 the resolver MUST: 1. Verify that the initial DNSKEY RR appears in the apex DNSKEY - RRset, and verify that the DNSKEY RR has the Zone Key Flag + 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 which covers the apex DNSKEY + 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. @@ -1387,25 +1443,26 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 authenticated NSEC RRsets from the zone to prove that an RRset is not present in the zone. - When a resolver indicates support for DNSSEC, 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 which that lacks - the appropriate DNSSEC RRs, whether due to configuration issues such - as a security-oblivious recursive name server which accidentally + 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 June 16, 2004 [Page 25] +Arends, et al. Expires August 16, 2004 [Page 26] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 - 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. + 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 @@ -1448,17 +1505,17 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 parent's apex DNSKEY RRset (see Section 5.3); o The Algorithm and Key Tag in the DS RR match the Algorithm field - and the key tag of a DNSKEY RR in the child zone's apex DNSKEY -Arends, et al. Expires June 16, 2004 [Page 26] +Arends, et al. Expires August 16, 2004 [Page 27] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 - RRset which, when hashed using the digest algorithm specified in - the DS RR's Digest Type field, results in a digest value which + 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 @@ -1474,10 +1531,10 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 a NSEC RRset proving that the DS RRset does not exist (see Section 4). - If the resolver authenticates an NSEC RRset which proves that no DS + 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 which belongs to the child zone or to any delegation + 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 @@ -1493,26 +1550,31 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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. - - - -Arends, et al. Expires June 16, 2004 [Page 27] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 5.3.1 Checking the RRSIG RR Validity A security-aware resolver can use an RRSIG RR to authenticate an @@ -1556,19 +1618,19 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 which the resolver has + parent zone or matches a DS RR or DNSKEY RR that the resolver has been preconfigured to believe to be authentic. - - -Arends, et al. Expires June 16, 2004 [Page 28] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 5.3.2 Reconstructing the Signed Data Once the RRSIG RR has met the validity requirements described in @@ -1608,24 +1670,24 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 let fqdn = RRset's fully qualified domain name in canonical form - let fqdn_labels = 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 leftmost rrsig_label labels of the + name = "*." | the rightmost rrsig_label labels of the fqdn - - -Arends, et al. Expires June 16, 2004 [Page 29] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - - if rrsig_labels > 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. @@ -1650,7 +1712,7 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 which contains the corresponding NSEC RRset. If + 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. @@ -1667,20 +1729,20 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 - - - -Arends, et al. Expires June 16, 2004 [Page 30] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - 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. @@ -1723,20 +1785,20 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 - - - -Arends, et al. Expires June 16, 2004 [Page 31] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - according to the standard RRset authentication rules described in Section 5.3, then apply the NSEC RRsets as follows: @@ -1756,8 +1818,8 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 which - could have been used to generate a positive response. + 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 @@ -1782,15 +1844,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 - - - - - - -Arends, et al. Expires June 16, 2004 [Page 32] +Arends, et al. Expires August 16, 2004 [Page 33] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 6. IANA Considerations @@ -1800,10 +1856,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 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 [I-D.ietf-dnsext-ad-is-secure] - 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. + 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 @@ -1844,9 +1899,10 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 33] + +Arends, et al. Expires August 16, 2004 [Page 34] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 7. Security Considerations @@ -1900,9 +1956,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 34] +Arends, et al. Expires August 16, 2004 [Page 35] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 8. Acknowledgements @@ -1956,9 +2012,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 35] +Arends, et al. Expires August 16, 2004 [Page 36] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 Normative References @@ -1990,14 +2046,14 @@ Normative References [I-D.ietf-dnsext-dnssec-intro] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "DNS Security Introduction and Requirements", - draft-ietf-dnsext-dnssec-intro-07 (work in progress), - October 2003. + 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-05 (work in progress), - October 2003. + draft-ietf-dnsext-dnssec-records-07 (work in progress), + February 2004. @@ -2012,9 +2068,9 @@ Normative References -Arends, et al. Expires June 16, 2004 [Page 36] +Arends, et al. Expires August 16, 2004 [Page 37] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 Informative References @@ -2031,10 +2087,11 @@ Informative References [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. - [I-D.ietf-dnsext-delegation-signer] - Gudmundsson, O., "Delegation Signer Resource Record", - draft-ietf-dnsext-delegation-signer-15 (work in progress), - June 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-wcard-clarify] Halley, B. and E. Lewis, "Clarifying the Role of Wild Card @@ -2042,11 +2099,6 @@ Informative References draft-ietf-dnsext-wcard-clarify-02 (work in progress), September 2003. - [I-D.ietf-dnsext-ad-is-secure] - Wellington, B. and O. Gudmundsson, "Redefinition of DNS AD - bit", draft-ietf-dnsext-ad-is-secure-06 (work in - progress), June 2002. - Authors' Addresses @@ -2059,20 +2111,6 @@ Authors' Addresses EMail: roy.arends@telin.nl - - - - - - - - - -Arends, et al. Expires June 16, 2004 [Page 37] - -Internet-Draft DNSSEC Protocol Modifications December 2003 - - Matt Larson VeriSign, Inc. 21345 Ridgetop Circle @@ -2082,10 +2120,19 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 EMail: mlarson@verisign.com + + + + +Arends, et al. Expires August 16, 2004 [Page 38] + +Internet-Draft DNSSEC Protocol Modifications February 2004 + + Rob Austein - Internet Software Consortium - 40 Gavin Circle - Reading, MA 01867 + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 USA EMail: sra@isc.org @@ -2124,9 +2171,18 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 38] + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 39] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 Appendix A. Signed Zone Example @@ -2180,9 +2236,9 @@ Appendix A. Signed Zone Example -Arends, et al. Expires June 16, 2004 [Page 39] +Arends, et al. Expires August 16, 2004 [Page 40] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 5LtAM3ElSpRIIhAm4b2c69IMdwrU2Q== @@ -2236,9 +2292,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 40] +Arends, et al. Expires August 16, 2004 [Page 41] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 hxNyPE9Wn675NDH/IpB2LZzhrUtV9eEndid8 @@ -2292,9 +2348,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 41] +Arends, et al. Expires August 16, 2004 [Page 42] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 WNJ/ulvIFa20d0xtlB7jazNCZ3Y= ) @@ -2348,9 +2404,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 42] +Arends, et al. Expires August 16, 2004 [Page 43] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 btznHMFDIbtuw/tAX7xXH2pDDHY= ) @@ -2404,9 +2460,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 43] +Arends, et al. Expires August 16, 2004 [Page 44] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 D4ZubIon0XGe9fIjLnmb3pX/FUk= ) @@ -2460,9 +2516,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 44] +Arends, et al. Expires August 16, 2004 [Page 45] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 Appendix B. Example Responses @@ -2516,9 +2572,9 @@ B.1 Answer -Arends, et al. Expires June 16, 2004 [Page 45] +Arends, et al. Expires August 16, 2004 [Page 46] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 dFbnHuZ1tLirjzCYr8CsmF9bSIKLbiMRc/SD @@ -2572,9 +2628,9 @@ B.2 Name Error -Arends, et al. Expires June 16, 2004 [Page 46] +Arends, et al. Expires August 16, 2004 [Page 47] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 CSITjVX0IGrQgd+PKkaTxWQzG9TDZ2TtgnyM @@ -2628,9 +2684,9 @@ B.3 No Data Error -Arends, et al. Expires June 16, 2004 [Page 47] +Arends, et al. Expires August 16, 2004 [Page 48] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 VBU6+FZWzC2IJcc5liv2SXzyfiPu8diB9+Bj @@ -2684,9 +2740,9 @@ B.4 Referral to Signed Zone -Arends, et al. Expires June 16, 2004 [Page 48] +Arends, et al. Expires August 16, 2004 [Page 49] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 B.5 Referral to Unsigned Zone @@ -2740,9 +2796,9 @@ B.6 Wildcard Expansion -Arends, et al. Expires June 16, 2004 [Page 49] +Arends, et al. Expires August 16, 2004 [Page 50] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 Hl2+WpbMguW9gyPpdHqIYkKJbOrX2b4bz6WA @@ -2796,9 +2852,9 @@ B.7 Wildcard No Data Error -Arends, et al. Expires June 16, 2004 [Page 50] +Arends, et al. Expires August 16, 2004 [Page 51] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 ;; Header: QR AA DO RCODE=0 @@ -2852,9 +2908,9 @@ B.8 DS Child Zone No Data Error -Arends, et al. Expires June 16, 2004 [Page 51] +Arends, et al. Expires August 16, 2004 [Page 52] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 ;; Header: QR AA DO RCODE=0 @@ -2908,9 +2964,9 @@ Internet-Draft DNSSEC Protocol Modifications December 2003 -Arends, et al. Expires June 16, 2004 [Page 52] +Arends, et al. Expires August 16, 2004 [Page 53] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 Appendix C. Authentication Examples @@ -2964,9 +3020,9 @@ C.1.1 Authenticating the example DNSKEY RR -Arends, et al. Expires June 16, 2004 [Page 53] +Arends, et al. Expires August 16, 2004 [Page 54] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 matching "example" DNSKEY is found, the resolver checks this DNSKEY @@ -3020,9 +3076,9 @@ C.5 Referral to Unsigned Zone -Arends, et al. Expires June 16, 2004 [Page 54] +Arends, et al. Expires August 16, 2004 [Page 55] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 identical to that of the MX RRset discussed above. @@ -3076,9 +3132,9 @@ C.8 DS Child Zone No Data Error -Arends, et al. Expires June 16, 2004 [Page 55] +Arends, et al. Expires August 16, 2004 [Page 56] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 Intellectual Property Statement @@ -3106,7 +3162,7 @@ Intellectual Property Statement Full Copyright Statement - Copyright (C) The Internet Society (2003). All Rights Reserved. + 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 @@ -3132,9 +3188,9 @@ Full Copyright Statement -Arends, et al. Expires June 16, 2004 [Page 56] +Arends, et al. Expires August 16, 2004 [Page 57] -Internet-Draft DNSSEC Protocol Modifications December 2003 +Internet-Draft DNSSEC Protocol Modifications February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -3188,6 +3244,6 @@ Acknowledgement -Arends, et al. Expires June 16, 2004 [Page 57] +Arends, et al. Expires August 16, 2004 [Page 58] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt similarity index 86% rename from doc/draft/draft-ietf-dnsext-dnssec-records-06.txt rename to doc/draft/draft-ietf-dnsext-dnssec-records-07.txt index a4668b76e8..cfd3567f0a 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-06.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-07.txt @@ -2,7 +2,7 @@ DNS Extensions R. Arends Internet-Draft Telematica Instituut -Expires: June 16, 2004 R. Austein +Expires: August 16, 2004 R. Austein ISC M. Larson VeriSign @@ -10,11 +10,11 @@ Expires: June 16, 2004 R. Austein USC/ISI S. Rose NIST - December 17, 2003 + February 16, 2004 Resource Records for the DNS Security Extensions - draft-ietf-dnsext-dnssec-records-06 + draft-ietf-dnsext-dnssec-records-07 Status of this Memo @@ -36,11 +36,11 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 16, 2004. + This Internet-Draft will expire on August 16, 2004. Copyright Notice - Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract @@ -52,9 +52,9 @@ Abstract -Arends, et al. Expires June 16, 2004 [Page 1] +Arends, et al. Expires August 16, 2004 [Page 1] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 signature (RRSIG), and authenticated denial of existence (NSEC) @@ -108,9 +108,9 @@ Table of Contents -Arends, et al. Expires June 16, 2004 [Page 2] +Arends, et al. Expires August 16, 2004 [Page 2] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 20 @@ -164,9 +164,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 3] +Arends, et al. Expires August 16, 2004 [Page 3] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 1. Introduction @@ -174,7 +174,7 @@ Internet-Draft DNSSEC Resource Records December 2003 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 - ASCII representation. + presentation format (ASCII representation). 1.1 Background and Related Documents @@ -187,7 +187,7 @@ Internet-Draft DNSSEC Resource Records December 2003 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 definition of common + 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 @@ -220,9 +220,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 4] +Arends, et al. Expires August 16, 2004 [Page 4] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 An example correction to dnssec-editors might be: Page X says @@ -276,9 +276,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 5] +Arends, et al. Expires August 16, 2004 [Page 5] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 2. The DNSKEY Resource Record @@ -286,10 +286,10 @@ Internet-Draft DNSSEC Resource Records December 2003 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]. For example, 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 - these signatures to authenticate RRsets from the zone. + 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 @@ -324,19 +324,20 @@ Internet-Draft DNSSEC Resource Records December 2003 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. + 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, - then the DNSKEY record holds a key intended for use as a secure entry -Arends, et al. Expires June 16, 2004 [Page 6] +Arends, et al. Expires August 16, 2004 [Page 6] -Internet-Draft DNSSEC Resource Records December 2003 +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 @@ -359,7 +360,9 @@ Internet-Draft DNSSEC Resource Records December 2003 2.1.4 The Public Key Field - The Public Key Field holds the public key material itself. + 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 @@ -382,17 +385,16 @@ Internet-Draft DNSSEC Resource Records December 2003 The Public Key field MUST be represented as a Base64 encoding of the Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see [RFC1521] Section 5.2. - - -Arends, et al. Expires June 16, 2004 [Page 7] +Arends, et al. Expires August 16, 2004 [Page 7] -Internet-Draft DNSSEC Resource Records December 2003 +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. @@ -442,11 +444,9 @@ Internet-Draft DNSSEC Resource Records December 2003 - - -Arends, et al. Expires June 16, 2004 [Page 8] +Arends, et al. Expires August 16, 2004 [Page 8] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 3. The RRSIG Resource Record @@ -482,9 +482,9 @@ Internet-Draft DNSSEC Resource Records December 2003 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 individuals RRs within a RRset: individual RRSIG with the - same owner name will have different TTLs if the RRsets that they - cover have different TTLs. + 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 @@ -500,9 +500,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 9] +Arends, et al. Expires August 16, 2004 [Page 9] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 | Type Covered | Algorithm | Labels | @@ -551,25 +551,25 @@ Internet-Draft DNSSEC Resource Records December 2003 describes how to use the Labels field to reconstruct the original owner name. - The value of the Label field MUST NOT count either the null (root) + 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 June 16, 2004 [Page 10] +Arends, et al. Expires August 16, 2004 [Page 10] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 - present). The value of the Label field MUST be less than or equal to - the number of labels in the RRSIG owner name. For example, - "www.example.com." has a Label field value of 3, and "*.example.com." - has a Label field value of 2. Root (".") has a Label field value of - 0. + 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. - Note that, although the wildcard label is not included in the count - stored in the Label field of the RRSIG RR, the wildcard label is part - of the RRset's owner name when generating or verifying the signature. + 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 @@ -612,9 +612,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 11] +Arends, et al. Expires August 16, 2004 [Page 11] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 3.1.7 The Signer's Name Field @@ -632,13 +632,14 @@ Internet-Draft DNSSEC Resource Records December 2003 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. + 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 field. The RRset is in canonical form + 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 @@ -667,10 +668,9 @@ Internet-Draft DNSSEC Resource Records December 2003 - -Arends, et al. Expires June 16, 2004 [Page 12] +Arends, et al. Expires August 16, 2004 [Page 12] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 Any DNS names in the RDATA field of each RR MUST be in @@ -696,7 +696,7 @@ Internet-Draft DNSSEC Resource Records December 2003 The Original TTL field value MUST be represented as an unsigned decimal integer. - The Signature Inception Time and Expiration Time field values MUST be + 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); @@ -724,9 +724,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 13] +Arends, et al. Expires August 16, 2004 [Page 13] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 The following an RRSIG RR stores the signature for the A RRset of @@ -742,7 +742,7 @@ Internet-Draft DNSSEC Resource Records December 2003 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. + 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 @@ -780,9 +780,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 14] +Arends, et al. Expires August 16, 2004 [Page 14] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 4. The NSEC Resource Record @@ -807,7 +807,8 @@ Internet-Draft DNSSEC Resource Records December 2003 The NSEC RR is class independent. - The NSEC RR has no special TTL requirements. + 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 @@ -825,22 +826,22 @@ Internet-Draft DNSSEC Resource Records December 2003 4.1.1 The Next Domain Name Field The Next Domain Name field contains the owner name of the next - authoritative RRset in the canonical ordering of the zone; see + 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 - NSEC RR containing a compressed Next Domain Name field SHOULD -Arends, et al. Expires June 16, 2004 [Page 15] +Arends, et al. Expires August 16, 2004 [Page 15] -Internet-Draft DNSSEC Resource Records December 2003 +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 @@ -888,15 +889,16 @@ Internet-Draft DNSSEC Resource Records December 2003 bitmap is determined by the type code with the largest numerical value, within that block, among the set of RR types present at the NSEC RR's owner name. Trailing zero octets not specified MUST be - interpreted as zero octets. -Arends, et al. Expires June 16, 2004 [Page 16] +Arends, et al. Expires August 16, 2004 [Page 16] -Internet-Draft DNSSEC Resource Records December 2003 +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. @@ -930,9 +932,9 @@ Internet-Draft DNSSEC Resource Records December 2003 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 and NSEC - mnemonics indicate there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets - associated with the name alfa.example.com. + 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: @@ -943,16 +945,16 @@ Internet-Draft DNSSEC Resource Records December 2003 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 - -Arends, et al. Expires June 16, 2004 [Page 17] +Arends, et al. Expires August 16, 2004 [Page 17] -Internet-Draft DNSSEC Resource Records December 2003 +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 @@ -1002,11 +1004,9 @@ Internet-Draft DNSSEC Resource Records December 2003 - - -Arends, et al. Expires June 16, 2004 [Page 18] +Arends, et al. Expires August 16, 2004 [Page 18] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 5. The DS Resource Record @@ -1060,9 +1060,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 19] +Arends, et al. Expires August 16, 2004 [Page 19] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 5.1.1 The Key Tag Field @@ -1091,7 +1091,7 @@ Internet-Draft DNSSEC Resource Records December 2003 5.1.4 The Digest Field The DS record refers to a DNSKEY RR by including a digest of that - DNSKEY RR. The Digest field holds the digest. + 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, @@ -1105,8 +1105,8 @@ Internet-Draft DNSSEC Resource Records December 2003 The size of the digest may vary depending on the digest algorithm and - DNSKEY RR size. Currently, the only defined digest algorithm is - SHA-1, which produces a 20 octet digest. + 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 @@ -1116,9 +1116,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 20] +Arends, et al. Expires August 16, 2004 [Page 20] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 have Flags bit 7 set to value 1. If the key tag does not indicate a @@ -1172,9 +1172,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 21] +Arends, et al. Expires August 16, 2004 [Page 21] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 6. Canonical Form and Order of Resource Records @@ -1228,9 +1228,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 22] +Arends, et al. Expires August 16, 2004 [Page 22] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 replaced by the corresponding lowercase US-ASCII letters; @@ -1253,11 +1253,9 @@ Internet-Draft DNSSEC Resource Records December 2003 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 RDATA: first by RDATA length, shortest to - longest, then by the canonical form of the RDATA itself in the case - of length equality, treating the RDATA portion of the canonical form - of each RR as a left justified unsigned octet sequence. The absence - of an octet sorts before a zero octet. + 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 @@ -1284,9 +1282,11 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 23] + + +Arends, et al. Expires August 16, 2004 [Page 23] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 7. IANA Considerations @@ -1298,15 +1298,19 @@ Internet-Draft DNSSEC Resource Records December 2003 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. - [I-D.ietf-dnsext-delegation-signer] 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]. + 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 @@ -1320,9 +1324,8 @@ Internet-Draft DNSSEC Resource Records December 2003 DNS Security Algorithm Numbers entries at the time of writing and their status of use in DNSSEC. - [I-D.ietf-dnsext-delegation-signer] created an IANA registry for - DNSSEC DS Digest Types, and assigned value 0 to reserved and value - 1 to SHA-1. + [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 @@ -1334,71 +1337,68 @@ Internet-Draft DNSSEC Resource Records December 2003 [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 June 16, 2004 [Page 24] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arends, et al. Expires August 16, 2004 [Page 25] -Internet-Draft DNSSEC Resource Records December 2003 - - - Bit zero of Type Bit Map in NSEC RRs: The meaning of a value of 1 in - bit zero of the Type Bit Map of an NSEC RR can only be assigned by - a standards action. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires June 16, 2004 [Page 25] - -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 8. Security Considerations @@ -1408,7 +1408,7 @@ Internet-Draft DNSSEC Resource Records December 2003 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 Please see [I-D.ietf-dnsext-dnssec-protocol] additional security + 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 @@ -1452,9 +1452,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 26] +Arends, et al. Expires August 16, 2004 [Page 26] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 9. Acknowledgments @@ -1508,9 +1508,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 27] +Arends, et al. Expires August 16, 2004 [Page 27] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 Normative References @@ -1557,40 +1557,39 @@ Normative References [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. - [I-D.ietf-dnsext-delegation-signer] - Gudmundsson, O., "Delegation Signer Resource Record", - draft-ietf-dnsext-delegation-signer-15 (work in progress), - June 2003. - - - -Arends, et al. Expires June 16, 2004 [Page 28] - -Internet-Draft DNSSEC Resource Records December 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-07 (work in progress), - October 2003. + 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-03 (work in - progress), October 2003. + 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-11 (work in - progress), October 2003. + 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-05 - (work in progress), October 2003. + Signer", draft-ietf-dnsext-dnssec-2535typecode-change-06 + (work in progress), December 2003. @@ -1620,9 +1619,10 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 29] + +Arends, et al. Expires August 16, 2004 [Page 29] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 Informative References @@ -1646,9 +1646,9 @@ Authors' Addresses Rob Austein - Internet Software Consortium - 40 Gavin Circle - Reading, MA 01867 + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 USA EMail: sra@isc.org @@ -1676,9 +1676,9 @@ Authors' Addresses -Arends, et al. Expires June 16, 2004 [Page 30] +Arends, et al. Expires August 16, 2004 [Page 30] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 Scott Rose @@ -1732,9 +1732,9 @@ Internet-Draft DNSSEC Resource Records December 2003 -Arends, et al. Expires June 16, 2004 [Page 31] +Arends, et al. Expires August 16, 2004 [Page 31] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 Appendix A. DNSSEC Algorithm and Digest Types @@ -1788,9 +1788,9 @@ A.1.1 Private Algorithm Types -Arends, et al. Expires June 16, 2004 [Page 32] +Arends, et al. Expires August 16, 2004 [Page 32] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 domain name, which MUST NOT be compressed. The domain name indicates @@ -1844,9 +1844,9 @@ A.2 DNSSEC Digest Types -Arends, et al. Expires June 16, 2004 [Page 33] +Arends, et al. Expires August 16, 2004 [Page 33] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 Appendix B. Key Tag Calculation @@ -1900,9 +1900,9 @@ Appendix B. Key Tag Calculation -Arends, et al. Expires June 16, 2004 [Page 34] +Arends, et al. Expires August 16, 2004 [Page 34] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 */ @@ -1956,9 +1956,9 @@ B.1 Key Tag for Algorithm 1 (RSA/MD5) -Arends, et al. Expires June 16, 2004 [Page 35] +Arends, et al. Expires August 16, 2004 [Page 35] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 Intellectual Property Statement @@ -1986,7 +1986,7 @@ Intellectual Property Statement Full Copyright Statement - Copyright (C) The Internet Society (2003). All Rights Reserved. + 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 @@ -2012,9 +2012,9 @@ Full Copyright Statement -Arends, et al. Expires June 16, 2004 [Page 36] +Arends, et al. Expires August 16, 2004 [Page 36] -Internet-Draft DNSSEC Resource Records December 2003 +Internet-Draft DNSSEC Resource Records February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF @@ -2068,6 +2068,6 @@ Acknowledgement -Arends, et al. Expires June 16, 2004 [Page 37] +Arends, et al. Expires August 16, 2004 [Page 37]