From 0ec67eaaa41ebff562a6c080ccb4551cb92baccd Mon Sep 17 00:00:00 2001 From: cvs2git Date: Wed, 18 Nov 2009 23:58:05 +0000 Subject: [PATCH] This commit was manufactured by cvs2git to create tag 'v9_6_1_P2'. --- bin/tests/system/pending/ns1/named.conf | 38 - bin/tests/system/pending/ns2/example.db.in | 28 - bin/tests/system/pending/ns3/hostile.db | 27 - bin/tests/system/pending/ns3/mail.example.db | 28 - bin/tests/system/pending/ns4/named.conf | 37 - bin/tests/system/pending/setup.sh | 21 - ...-ietf-6man-text-addr-representation-01.txt | 785 -------- doc/draft/draft-ietf-behave-dns64-01.txt | 1624 ----------------- ...ft-ietf-dnsext-dns-tcp-requirements-01.txt | 448 ----- ...raft-ietf-dnsext-dnssec-bis-updates-09.txt | 672 ------- .../draft-ietf-dnsext-rfc2672bis-dname-18.txt | 953 ---------- .../draft-ietf-dnsext-rfc3597-bis-00.txt | 395 ---- ...aft-ietf-dnsext-tsig-md5-deprecated-03.txt | 336 ---- ...f-dnsop-name-server-management-reqs-02.txt | 952 ---------- doc/rfc/rfc1912.txt | 899 --------- doc/rfc/rfc4509.txt | 395 ---- doc/rfc/rfc4635.txt | 451 ----- doc/rfc/rfc4892.txt | 451 ----- doc/rfc/rfc5011.txt | 787 -------- doc/rfc/rfc5702.txt | 563 ------ 20 files changed, 9890 deletions(-) delete mode 100644 bin/tests/system/pending/ns1/named.conf delete mode 100644 bin/tests/system/pending/ns2/example.db.in delete mode 100644 bin/tests/system/pending/ns3/hostile.db delete mode 100644 bin/tests/system/pending/ns3/mail.example.db delete mode 100644 bin/tests/system/pending/ns4/named.conf delete mode 100644 bin/tests/system/pending/setup.sh delete mode 100644 doc/draft/draft-ietf-6man-text-addr-representation-01.txt delete mode 100644 doc/draft/draft-ietf-behave-dns64-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt delete mode 100644 doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt delete mode 100644 doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt delete mode 100644 doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt delete mode 100644 doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt delete mode 100644 doc/rfc/rfc1912.txt delete mode 100644 doc/rfc/rfc4509.txt delete mode 100644 doc/rfc/rfc4635.txt delete mode 100644 doc/rfc/rfc4892.txt delete mode 100644 doc/rfc/rfc5011.txt delete mode 100644 doc/rfc/rfc5702.txt diff --git a/bin/tests/system/pending/ns1/named.conf b/bin/tests/system/pending/ns1/named.conf deleted file mode 100644 index b23843f597a..00000000000 --- a/bin/tests/system/pending/ns1/named.conf +++ /dev/null @@ -1,38 +0,0 @@ -/* - * Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH - * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY - * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, - * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM - * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE - * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - * PERFORMANCE OF THIS SOFTWARE. - */ - -/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */ - -controls { /* empty */ }; - -include "trusted.conf"; - -options { - query-source address 10.53.0.1; - notify-source 10.53.0.1; - transfer-source 10.53.0.1; - port 5300; - pid-file "named.pid"; - listen-on { 10.53.0.1; }; - listen-on-v6 { none; }; - recursion no; -}; - -zone "." { - type master; - file "root.db.signed"; -}; - diff --git a/bin/tests/system/pending/ns2/example.db.in b/bin/tests/system/pending/ns2/example.db.in deleted file mode 100644 index ca0d596b211..00000000000 --- a/bin/tests/system/pending/ns2/example.db.in +++ /dev/null @@ -1,28 +0,0 @@ -; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") -; -; Permission to use, copy, modify, and/or distribute this software for any -; purpose with or without fee is hereby granted, provided that the above -; copyright notice and this permission notice appear in all copies. -; -; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH -; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY -; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, -; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM -; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE -; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR -; PERFORMANCE OF THIS SOFTWARE. - -; $Id: example.db.in,v 1.2 2009/11/17 23:55:18 marka Exp $ - -$TTL 30 -@ IN SOA mname1. . ( - 2009110300 ; serial - 20 ; refresh (20 seconds) - 20 ; retry (20 seconds) - 1814400 ; expire (3 weeks) - 3600 ; minimum (1 hour) - ) - NS ns2 - MX 10 mail -ns2 A 10.53.0.2 -mail A 10.0.0.2 diff --git a/bin/tests/system/pending/ns3/hostile.db b/bin/tests/system/pending/ns3/hostile.db deleted file mode 100644 index 2a2d3501df3..00000000000 --- a/bin/tests/system/pending/ns3/hostile.db +++ /dev/null @@ -1,27 +0,0 @@ -; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") -; -; Permission to use, copy, modify, and/or distribute this software for any -; purpose with or without fee is hereby granted, provided that the above -; copyright notice and this permission notice appear in all copies. -; -; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH -; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY -; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, -; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM -; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE -; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR -; PERFORMANCE OF THIS SOFTWARE. - -; $Id: hostile.db,v 1.2 2009/11/17 23:55:18 marka Exp $ - -$TTL 30 -@ IN SOA mname1. . ( - 2009110500 ; serial - 20 ; refresh (20 seconds) - 20 ; retry (20 seconds) - 1814400 ; expire (3 weeks) - 3600 ; minimum (1 hour) - ) - NS ns3 - MX 10 mail.example. -ns3 A 10.53.0.3 diff --git a/bin/tests/system/pending/ns3/mail.example.db b/bin/tests/system/pending/ns3/mail.example.db deleted file mode 100644 index d56f9f01ed7..00000000000 --- a/bin/tests/system/pending/ns3/mail.example.db +++ /dev/null @@ -1,28 +0,0 @@ -; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") -; -; Permission to use, copy, modify, and/or distribute this software for any -; purpose with or without fee is hereby granted, provided that the above -; copyright notice and this permission notice appear in all copies. -; -; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH -; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY -; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, -; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM -; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE -; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR -; PERFORMANCE OF THIS SOFTWARE. - -; $Id: mail.example.db,v 1.2 2009/11/17 23:55:18 marka Exp $ - -$TTL 30 -@ IN SOA mname1. . ( - 2009110300 ; serial - 20 ; refresh (20 seconds) - 20 ; retry (20 seconds) - 1814400 ; expire (3 weeks) - 3600 ; minimum (1 hour) - ) -@ NS ns3 -ns3 A 10.53.0.3 -;mail A 10.0.0.2 // the correct record -@ A 10.0.0.3 diff --git a/bin/tests/system/pending/ns4/named.conf b/bin/tests/system/pending/ns4/named.conf deleted file mode 100644 index 8c941496e23..00000000000 --- a/bin/tests/system/pending/ns4/named.conf +++ /dev/null @@ -1,37 +0,0 @@ -/* - * Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH - * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY - * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, - * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM - * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE - * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR - * PERFORMANCE OF THIS SOFTWARE. - */ - -/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */ - -controls { /* empty */ }; - -include "trusted.conf"; - -options { - query-source address 10.53.0.4; - notify-source 10.53.0.4; - transfer-source 10.53.0.4; - port 5300; - pid-file "named.pid"; - listen-on { 10.53.0.4; }; - listen-on-v6 { none; }; - recursion yes; -}; - -zone "." { - type hint; - file "../../common/root.hint"; -}; diff --git a/bin/tests/system/pending/setup.sh b/bin/tests/system/pending/setup.sh deleted file mode 100644 index 5332d36de61..00000000000 --- a/bin/tests/system/pending/setup.sh +++ /dev/null @@ -1,21 +0,0 @@ -#!/bin/sh -e -# -# Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC") -# -# Permission to use, copy, modify, and/or distribute this software for any -# purpose with or without fee is hereby granted, provided that the above -# copyright notice and this permission notice appear in all copies. -# -# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH -# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY -# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, -# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM -# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE -# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR -# PERFORMANCE OF THIS SOFTWARE. - -# $Id: setup.sh,v 1.2 2009/11/17 23:55:18 marka Exp $ - -../../../tools/genrandom 400 random.data - -cd ns1 && sh -e sign.sh diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt deleted file mode 100644 index f15b069b5ba..00000000000 --- a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt +++ /dev/null @@ -1,785 +0,0 @@ - - - -IPv6 Maintenance Working Group S. Kawamura -Internet-Draft NEC BIGLOBE, Ltd. -Intended status: Informational M. Kawashima -Expires: April 21, 2010 NEC AccessTechnica, Ltd. - October 18, 2009 - - - A Recommendation for IPv6 Address Text Representation - draft-ietf-6man-text-addr-representation-01 - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 21, 2010. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - As IPv6 network grows, there will be more engineers and also non- - engineers who will have the need to use an IPv6 address in text. - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 1] - -Internet-Draft IPv6 Text Representation October 2009 - - - While the IPv6 address architecture RFC 4291 section 2.2 depicts a - flexible model for text representation of an IPv6 address, this - flexibility has been causing problems for operators, system - engineers, and users. This document will describe the problems that - a flexible text representation has been causing. This document also - recommends a canonical representation format that best avoids - confusion. It is expected that the canonical format is followed by - humans and systems when representing IPv6 addresses as text, but all - implementations must accept and be able to handle any legitimate - RFC4291 format. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 - 2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4 - 2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4 - 2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5 - 2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5 - 3. Problems Encountered with the Flexible Model . . . . . . . . . 6 - 3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6 - 3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6 - 3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6 - 3.1.4. Searching for an Address in a Network Diagram . . . . 7 - 3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7 - 3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7 - 3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8 - 3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8 - 3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8 - 3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8 - 3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8 - 3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9 - 3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9 - 3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9 - 3.4.2. Preference in Documentation . . . . . . . . . . . . . 9 - 3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 10 - 4. A Recommendation for IPv6 Text Representation . . . . . . . . 10 - 4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10 - 4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10 - 4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10 - 4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10 - 4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11 - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 2] - -Internet-Draft IPv6 Text Representation October 2009 - - - 5. Text Representation of Special Addresses . . . . . . . . . . . 11 - 6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11 - 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 - 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 - Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13 - Appendix B. Prefix Issues . . . . . . . . . . . . . . . . . . . . 13 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 3] - -Internet-Draft IPv6 Text Representation October 2009 - - -1. Introduction - - A single IPv6 address can be text represented in many ways. Examples - are shown below. - - 2001:db8:0:0:1:0:0:1 - - 2001:0db8:0:0:1:0:0:1 - - 2001:db8::1:0:0:1 - - 2001:db8::0:1:0:0:1 - - 2001:0db8::1:0:0:1 - - 2001:db8:0:0:1::1 - - 2001:db8:0000:0:1::1 - - 2001:DB8:0:0:1::1 - - All the above point to the same IPv6 address. This flexibility has - caused many problems for operators, systems engineers, and customers. - The problems will be noted in Section 3. Also, a canonical - representation format to avoid problems will be introduced in - Section 4. - -1.1. Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -2. Text Representation Flexibility of RFC4291 - - Examples of flexibility in Section 2.2 of [RFC4291] are described - below. - -2.1. Leading Zeros in a 16 Bit Field - - 'It is not necessary to write the leading zeros in an individual - field.' - - In other words, it is also not necessary to omit leading zeros. This - means that, it is possible to select from such as the following - example. The final 16 bit field is different, but all these - addresses mean the same. - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 4] - -Internet-Draft IPv6 Text Representation October 2009 - - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001 - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:001 - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:01 - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:1 - -2.2. Zero Compression - - 'A special syntax is available to compress the zeros. The use of - "::" indicates one or more groups of 16 bits of zeros.' - - It is possible to select whether or not to omit just one 16 bits of - zeros. - - 2001:db8:aaaa:bbbb:cccc:dddd::1 - - 2001:db8:aaaa:bbbb:cccc:dddd:0:1 - - In case where there are more than one zero fields, there is a choice - of how many fields can be shortened. Examples follow. - - 2001:db8:0:0:0::1 - - 2001:db8:0:0::1 - - 2001:db8:0::1 - - 2001:db8::1 - - In addition, [RFC4291] in section 2.2 notes, - - 'The "::" can only appear once in an address.' - - This gives a choice on where, in a single address to compress the - zero. Examples are shown below. - - 2001:db8::aaaa:0:0:1 - - 2001:db8:0:0:aaaa::1 - -2.3. Uppercase or Lowercase - - [RFC4291] does not mention about preference of uppercase or - lowercase. Various flavors are shown below. - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 5] - -Internet-Draft IPv6 Text Representation October 2009 - - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA - - 2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa - - -3. Problems Encountered with the Flexible Model - -3.1. Searching - -3.1.1. General Summary - - A search of an IPv6 address if conducted through a UNIX system is - usually case sensitive and extended options to allow for regular - expression use will come in handy. However, there are many - applications in the Internet today that do not provide this - capability. When searching for an IPv6 address in such systems, the - system engineer will have to try each and every possibility to search - for an address. This has critical impacts especially when trying to - deploy IPv6 over an enterprise network. - -3.1.2. Searching Spreadsheets and Text Files - - Spreadsheet applications and text editors on GUI systems, rarely have - the ability to search for a text using regular expression. Moreover, - there are many non-engineers (who are not aware of case sensitivity - and regular expression use) that use these application to manage IP - addresses. This has worked quite well with IPv4 since text - representation in IPv4 has very little flexibility. There is no - incentive to encourage these non-engineers to change their tool or - learn regular expression when they decide to go dual-stack. If the - entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was - conducted as 2001:db8:0:0:1::1, this will show a result of no match. - One example where this will cause problem is, when the search is - being conducted to assign a new address from a pool, and a check was - being done to see if it was not in use. This may cause problems to - the end-hosts or end-users. This type of address management is very - often seen in enterprise networks and also in ISPs. - -3.1.3. Searching with Whois - - The "whois" utility is used by a wide range of people today. When a - record is set to a database, one will likely check the output to see - if the entry is correct. If an entity was recorded as 2001:db8::/48, - but the whois output showed 2001:0db8:0000::/48, most non-engineers - would think that their input was wrong, and will likely retry several - times or make a frustrated call to the database hostmaster. If there - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 6] - -Internet-Draft IPv6 Text Representation October 2009 - - - was a need to register the same address on different systems, and - each system showed a different text representation, this would - confuse people even more. Although this document focuses on - addresses rather than prefixes, this is worth mentioning since - problems encountered are mostly equal. - -3.1.4. Searching for an Address in a Network Diagram - - Network diagrams and blue-prints contain IP addresses as allocated to - system devices. In times of trouble shooting, there may be a need to - search through a diagram to find the point of failure (for example, - if a traceroute stopped at 2001:db8::1, one would search the diagram - for that address). This is a technique quite often in use in - enterprise networks and managed services. Again, the different - flavors of text representation will result in a time-consuming - search, leading to longer MTTR in times of trouble. - -3.2. Parsing and Modifying - -3.2.1. General Summary - - With all the possible text representation ways, each application must - include a module, object, link, etc. to a function that will parse - IPv6 addresses in a manner that no matter how it is represented, they - will mean the same address. This is not too much a problem if the - output is to be just 'read' or 'managed' by a network engineer. - However, many system engineers who integrate complex computer systems - to corporate customers will have difficulties finding that their - favorite tool will not have this function, or will encounter - difficulties such as having to rewrite their macro's or scripts for - their customers. It must be noted that each additional line of a - program will result in increased development fees that will be - charged to the customers. - -3.2.2. Logging - - If an application were to output a log summary that represented the - address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444), - the output would be highly unreadable compared to the IPv4 output. - The address would have to be parsed and reformed to make it useful - for human reading. This will result in additional code on the - applications which will result in extra fees charged to the - customers. Sometimes, logging for critical systems is done by - mirroring the same traffic to two different systems. Care must be - taken that no matter what the log output is, the logs should be - parsed so they will mean the same. - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 7] - -Internet-Draft IPv6 Text Representation October 2009 - - -3.2.3. Auditing: Case 1 - - When a router or any other network appliance machine configuration is - audited, there are many methods to compare the configuration - information of a node. Sometimes, auditing will be done by just - comparing the changes made each day. In this case, if configuration - was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000: - 0000:0000:0000:0001 just because the new engineer on the block felt - it was better, a simple diff will tell you that a different address - was configured. If this was done on a wide scale network, people - will be focusing on 'why the extra zeros were put in' instead of - doing any real auditing. Lots of tools are just plain 'diff's that - do not take into account address representation rules. - -3.2.4. Auditing: Case 2 - - Node configurations will be matched against an information system - that manages IP addresses. If output notation is different, there - will need to be a script that is implemented to cover for this. An - SNMP GET of an interface address and text representation in a humanly - written text file is highly unlikely to match on first try. - -3.2.5. Verification - - Some protocols require certain data fields to be verified. One - example of this is X.509 certificates. If an IPv6 address was - embedded in one of the fields in a certificate, and the verification - was done by just a simple textual comparison, the certificate may be - maistakenly shown as being invalid due to a difference in text - representation methods. - -3.2.6. Unexpected Modifying - - Sometimes, a system will take an address and modify it as a - convenience. For example, a system may take an input of - 2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some - RIR databases). If the zeros were input for a reason, the outcome - may be somewhat unexpected. - -3.3. Operating - -3.3.1. General Summary - - When an operator sets an IPv6 address of a system as 2001:db8:0:0:1: - 0:0:1, the system may take the address and show the configuration - result as 2001:DB8::1:0:0:1. A distinguished engineer will know that - the right address is set, but an operator, or a customer that is - communicating with the operator to solve a problem, is usually not as - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 8] - -Internet-Draft IPv6 Text Representation October 2009 - - - distinguished as we would like. Again, the extra load in checking - that the IP address is the same as was intended, will result in fees - that will be charged to the customers. - -3.3.2. Customer Calls - - When a customer calls to inquire about a suspected outage, IPv6 - address representation should be handled with care. Not all - customers are engineers nor have the same skill in IPv6 technology. - The NOC will have to take extra steps to humanly parse the address to - avoid having to explain to the customers that 2001:db8:0:1::1 is the - same as 2001:db8::1:0:0:0:1. This is one thing that will never - happen in IPv4 because IPv4 address cannot be abbreviated. - -3.3.3. Abuse - - Network abuse is reported along with the abusing IP address. This - 'reporting' could take any shape or form of the flexible model. A - team that handles network abuse must be able to tell the difference - between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the - placement of the "::" will result in a critical situation. A system - that handles these incidents should be able to handle any type of - input and parse it in a correct manner. Also, incidents are reported - over the phone. It is unnecessary to report if the letter is an - uppercase or lowercase. However, when a letter is spelled uppercase, - people tend to clarify that it is uppercase, which is unnecessary - information. - -3.4. Other Minor Problems - -3.4.1. Changing Platforms - - When an engineer decides to change the platform of a running service, - the same code may not work as expected due to the difference in IPv6 - address text representation. Usually, a change in a platform (e.g. - Unix to Windows, Cisco to Juniper) will result in a major change of - code, but flexibility in address representation will increase the - work load which will again, result in fees that will be charged to - the customers, and also longer down time of systems. - -3.4.2. Preference in Documentation - - A document that is edited by more than one author, may become harder - to read. - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 9] - -Internet-Draft IPv6 Text Representation October 2009 - - -3.4.3. Legibility - - Capital case D and 0 can be quite often misread. Capital B and 8 can - also be misread. - - -4. A Recommendation for IPv6 Text Representation - - A recommendation for a canonical text representation format of IPv6 - addresses is presented in this section. The recommendation in this - document is one that, complies fully with [RFC4291], is implemented - by various operating systems, and is human friendly. The - recommendation in this document SHOULD be followed by humans and - systems when generating an address to represent as text, but all - implementations MUST accept any legitimate [RFC4291] format. - -4.1. Handling Leading Zeros in a 16 Bit Field - - Leading zeros should be chopped for human legibility and easier - searching. Also, a single 16 bit 0000 field should be represented as - just 0. Place holder zeros are often cause of misreading. - -4.2. "::" Usage - -4.2.1. Shorten As Much As Possible - - The use of "::" should be used to its maximum capability (i.e. 2001: - db8::0:1 is not considered as clean representation). - -4.2.2. Handling One 16 Bit 0 Field - - "::" should not be used to shorten just one 16 bit 0 field for it - would tend to mislead that there are more than one 16 bit field that - is shortened. - -4.2.3. Choice in Placement of "::" - - When there is an alternative choice in the placement of a "::", the - longest run of consecutive 16 bit 0 fields should be shortened (i.e. - latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the - consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1), - the former is shortened. This is consistent with many current - implementations. One idea to avoid any confusion, is for the - operator to not use 16 bit field 0 in the first 64 bits. By nature - IPv6 addresses are usually assigned or allocated to end-users as - longer than 32 bits (typically 48 bits or longer). - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 10] - -Internet-Draft IPv6 Text Representation October 2009 - - -4.3. Lower Case - - Recent implementations tend to represent IPv6 address as lower case. - It is better to use lower case to avoid problems such as described in - section 3.3.3 and 3.4.3. - - -5. Text Representation of Special Addresses - - Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and - IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in - the low-order 32 bits of the address. These addresses have special - representation that may mix hexadecimal and decimal notations. In - cases where there is a choice of whether to express the address as - fully hexadecimal or hexadecimal and decimal mixed, and if the - address type can be distinguished as having IPv4 addresses embedded - in the lower 32 bits solely from the 128bits of the address field - itself, mixed notation is the better choice. However, there may be - situations where hexadecimal representation is chosen to meet certain - needs. Addressing those needs is out of the scope of this document. - The text representation method noted in Section 4 should be applied - for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of - 0:0:0:0:0:ffff:192.0.2.1). - - -6. Notes on Combining IPv6 Addresses with Port Numbers - - When IPv6 addresses and port numbers are represented in text combined - together, there seems to be many different ways to do so. Examples - are shown below. - - o [2001:db8::1]:80 - - o 2001:db8::1:80 - - o 2001:db8::1.80 - - o 2001:db8::1 port 80 - - o 2001:db8::1p80 - - o 2001:db8::1#80 - - The situation is not much different in IPv4, but the most ambiguous - case with IPv6 is the second bullet. This is due to the "::"usage in - IPv6 addresses. This style is not recommended for its ambiguity. - The [] style as expressed in [RFC3986] is recommended. Other styles - are acceptable when cross-platform portability does not become an - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 11] - -Internet-Draft IPv6 Text Representation October 2009 - - - issue. - - -7. Conclusion - - The recommended format of text representing an IPv6 address is - summarized as follows. - - (1) omit leading zeros in a 16 bit field - - (2) when using "::", shorten consecutive zero fields to their - maximum extent (leave no zero fields behind). - - (3) "::" used where shortens address the most - - (4) "::" used in the former part in case of a tie breaker - - (5) do not shorten one 16 bit 0 field, but always shorten when - there are two or more consecutive 16 bit 0 fields - - (6) use lower case - - Hints for developers are written in the Appendix section. - - -8. Security Considerations - - None. - - -9. IANA Considerations - - None. - - -10. Acknowledgements - - The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami, - Toshimitsu Matsuura for their generous and helpful comments in kick - starting this document. We also would like to thank Brian Carpenter, - Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler, - Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki - Vatiainen for their input. Also a very special thanks to Ron Bonica, - Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt - Lindqvist for their support in bringing this document to the light of - IETF working groups. - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 12] - -Internet-Draft IPv6 Text Representation October 2009 - - -11. References - -11.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, February 2006. - -11.2. Informative References - - [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm - (SIIT)", RFC 2765, February 2000. - - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, - RFC 3986, January 2005. - - [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. - Castro, "Application Aspects of IPv6 Transition", - RFC 4038, March 2005. - - [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site - Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, - March 2008. - - -Appendix A. For Developers - - We recommend that developers use display routines that conform to - these rules. For example, the usage of getnameinfo() with flags - argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output, - except for the special addresses notes in Section 5. The function - inet_ntop() of FreeBSD7.0 is a good C code reference, but should not - be called directly. See [RFC4038] for details. - - -Appendix B. Prefix Issues - - Problems with prefixes are just the same as problems encountered with - addresses. Text representation method of IPv6 prefixes should be no - different from that of IPv6 addresses. - - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 13] - -Internet-Draft IPv6 Text Representation October 2009 - - -Authors' Addresses - - Seiichi Kawamura - NEC BIGLOBE, Ltd. - 14-22, Shibaura 4-chome - Minatoku, Tokyo 108-8558 - JAPAN - - Phone: +81 3 3798 6085 - Email: kawamucho@mesh.ad.jp - - - Masanobu Kawashima - NEC AccessTechnica, Ltd. - 800, Shimomata - Kakegawa-shi, Shizuoka 436-8501 - JAPAN - - Phone: +81 537 23 9655 - Email: kawashimam@necat.nec.co.jp - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Kawamura & Kawashima Expires April 21, 2010 [Page 14] - - diff --git a/doc/draft/draft-ietf-behave-dns64-01.txt b/doc/draft/draft-ietf-behave-dns64-01.txt deleted file mode 100644 index 25a6dd4d072..00000000000 --- a/doc/draft/draft-ietf-behave-dns64-01.txt +++ /dev/null @@ -1,1624 +0,0 @@ - - - -BEHAVE WG M. Bagnulo -Internet-Draft UC3M -Intended status: Standards Track A. Sullivan -Expires: April 22, 2010 Shinkuro - P. Matthews - Alcatel-Lucent - I. van Beijnum - IMDEA Networks - October 19, 2009 - - -DNS64: DNS extensions for Network Address Translation from IPv6 Clients - to IPv4 Servers - draft-ietf-behave-dns64-01 - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 22, 2010. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 1] - -Internet-Draft DNS64 October 2009 - - -Abstract - - DNS64 is a mechanism for synthesizing AAAA records from A records. - DNS64 is used with an IPv6/IPv4 translator to enable client-server - communication between an IPv6-only client and an IPv4-only server, - without requiring any changes to either the IPv6 or the IPv4 node, - for the class of applications that work through NATs. This document - specifies DNS64, and provides suggestions on how it should be - deployed in conjunction with IPv6/IPv4 translators. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Background to DNS64 - DNSSEC interaction . . . . . . . . . . . 6 - 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9 - 5.1. Resolving AAAA queries and the answer section . . . . . . 9 - 5.1.1. The answer when there is AAAA data available . . . . . 9 - 5.1.2. The answer when there is an error . . . . . . . . . . 9 - 5.1.3. Data for the answer when performing synthesis . . . . 9 - 5.1.4. Performing the synthesis . . . . . . . . . . . . . . . 10 - 5.1.5. Querying in parallel . . . . . . . . . . . . . . . . . 11 - 5.2. Generation of the IPv6 representations of IPv4 - addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.3. Handling other RRs . . . . . . . . . . . . . . . . . . . . 12 - 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 12 - 5.3.2. Handling the additional section . . . . . . . . . . . 13 - 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 13 - 5.4. Assembling a synthesized response to a AAAA query . . . . 14 - 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 14 - 5.6. DNS64 and multihoming . . . . . . . . . . . . . . . . . . 15 - 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 16 - 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 16 - 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 16 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Appendix A. Deployment scenarios and examples . . . . . . . . . . 20 - A.1. Embed and Zero-Pad algorithm description . . . . . . . . . 21 - A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in - DNS server mode . . . . . . . . . . . . . . . . . . . . . 22 - A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in - stub-resolver mode . . . . . . . . . . . . . . . . . . . . 23 - - - -Bagnulo, et al. Expires April 22, 2010 [Page 2] - -Internet-Draft DNS64 October 2009 - - - A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS - server mode . . . . . . . . . . . . . . . . . . . . . . . 25 - Appendix B. Motivations and Implications of synthesizing AAAA - RR when real AAAA RR exists . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 3] - -Internet-Draft DNS64 October 2009 - - -1. Introduction - - This document specifies DNS64, a mechanism that is part of the - toolbox for IPv6-IPv4 transition and co-existence. DNS64, used - together with an IPv6/IPv4 translator such as NAT64 - [I-D.bagnulo-behave-nat64], allows an IPv6-only client to initiate - communications by name to an IPv4-only server. - - DNS64 is a mechanism for synthesizing AAAA resource records (RRs) - from A RRs. A synthetic AAAA RR created by the DNS64 from an - original A RR contains the same FQDN of the original A RR but it - contains an IPv6 address instead of an IPv4 address. The IPv6 - address is an IPv6 representation of the IPv4 address contained in - the original A RR. The IPv6 representation of the IPv4 address is - algorithmically generated from the IPv4 address returned in the A RR - and a set of parameters configured in the DNS64 (typically, an IPv6 - prefix used by IPv6 representations of IPv4 addresses and optionally - other parameters). - - Together with a IPv6/IPv4 translator, these two mechanisms allow an - IPv6-only client to initiate communications to an IPv4-only server - using the FQDN of the server. - - These mechanisms are expected to play a critical role in the IPv4- - IPv6 transition and co-existence. Due to IPv4 address depletion, it - is likely that in the future, many IPv6-only clients will want to - connect to IPv4-only servers. In the typical case, the approach only - requires the deployment of IPv6/IPv4 translators that connect an - IPv6-only network to an IPv4-only network, along with the deployment - of one or more DNS64-enabled name servers. However, some advanced - features require performing the DNS64 function directly by the end- - hosts themselves. - - -2. Overview - - This section provides a non-normative introduction to the DNS64 - mechanism. - - We assume that we have an IPv6/IPv4 translator box connecting an IPv4 - network and an IPv6 network. The IPv6/IPv4 translator device - provides translation services between the two networks enabling - communication between IPv4-only hosts and IPv6-only hosts. (NOTE: By - IPv6-only hosts we mean hosts running IPv6-only applications, hosts - that can only use IPv6, as well as the cases where only IPv6 - connectivity is available to the client. By IPv4-only servers we - mean servers running IPv4-only applications, servers that can only - use IPv4, as well as the cases where only IPv4 connectivity is - - - -Bagnulo, et al. Expires April 22, 2010 [Page 4] - -Internet-Draft DNS64 October 2009 - - - available to the server). The IPv6/IPv4 translator used in - conjunction with DNS64 must allow communications initiated from the - IPv6-only host to the IPv4-only host. - - To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to - learn the address of the responder, DNS64 is used to synthesize a - AAAA record from an A record containing a real IPv4 address of the - responder, whenever the DNS64 service cannot retrieve a AAAA record - for the requested host name. The DNS64 device appears as a regular - recursive resolver for the IPv6 initiator. The DNS64 box receives an - AAAA DNS query generated by the IPv6 initiator. It first attempts a - recursive resolution for the requested AAAA records. If there is no - AAAA record available for the target node (which is the normal case - when the target node is an IPv4-only node), DNS64 performs a query - for A records. If any A records are discovered, DNS64 creates a - synthetic AAAA RR from the information retrieved in each A RR. - - The FQDN of a synthetic AAAA RR is the same as that of the original A - RR, but an IPv6 representation of the IPv4 address contained in the - original A RR is included in the AAAA RR. The IPv6 representation of - the IPv4 address is algorithmically generated from the IPv4 address - and additional parameters configured in the DNS64. Among those - parameters configured in the DNS64, there is at least one IPv6 - prefix, called Pref64::/n. The IPv6 address representing IPv4 - addresses included in the AAAA RR synthesized by the DNS64 function - contain Pref64::/n and they also embed the original IPv4 address. - - The same algorithm and the same Pref64::/n prefix or prefixes must be - configured both in the DNS64 device and the IPv6/IPv4 translator, so - that both can algorithmically generate the same IPv6 representation - for a given IPv4 address. In addition, it is required that IPv6 - packets addressed to an IPv6 destination that contains the Pref64::/n - be delivered to the IPv6/IPv4 translator, so they can be translated - into IPv4 packets. - - Once the DNS64 has synthesized the AAAA RR, the synthetic AAAA RR is - passed back to the IPv6 initiator, which will initiate an IPv6 - communication with the IPv6 address associated with the IPv4 - receiver. The packet will be routed to the IPv6/IPv4 translator - which will forward it to the IPv4 network . - - In general, the only shared state between the DNS64 and the IPv6/IPv4 - translator is the Pref64::/n and an optional set of static - parameters. The Pref64::/n and the set of static parameters must be - configured to be the same on both; there is no communication between - the DNS64 device and IPv6/IPv4 translator functions. The mechanism - to be used for configuring the parameters of the DNS64 is beyond the - scope of this memo. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 5] - -Internet-Draft DNS64 October 2009 - - - The DNS64 function can be performed in two places. - - One option is to locate the DNS64 function in recursive name - servers serving end hosts. In this case, when an IPv6-only host - queries the name server for AAAA RRs for an IPv4-only host, the - name server can perform the synthesis of AAAA RRs and pass them - back to the IPv6 only initiator. The main advantage of this mode - is that current IPv6 nodes can use this mechanism without - requiring any modification. This mode is called "DNS64 in DNS - server mode". - - The other option is to place the DNS64 function in the end hosts - themselves, coupled to the local stub resolver. In this case, the - stub resolver will try to obtain (real) AAAA RRs and in case they - are not available, the DNS64 function will synthesize AAAA RRs for - internal usage. This mode is compatible with some advanced - functions like DNSSEC validation in the end host. The main - drawback of this mode is its deployability, since it requires - changes in the end hosts. This mode is called "DNS64 in stub- - resolver mode"". - - -3. Background to DNS64 - DNSSEC interaction - - DNSSEC presents a special challenge for DNS64, because DNSSEC is - designed to detect changes to DNS answers, and DNS64 may alter - answers coming from an authoritative server. - - A recursive resolver can be security-aware or security-oblivious. - Moreover, a security-aware recursive name server can be validating or - non-validating, according to operator policy. In the cases below, - the recursive server is also performing DNS64, and has a local policy - to validate. We call this general case vDNS64, but in all the cases - below the DNS64 functionality should be assumed needed. - - DNSSEC includes some signaling bits that offer some indicators of - what the query originator understands. - - If a query arrives at a vDNS64 device with the DO bit set, the query - originator is signaling that it understands DNSSEC. The DO bit does - not indicate that the query originator will validate the response. - It only means that the query originator can understand responses - containing DNSSEC data. Conversely, if the DO bit is clear, that is - evidence that the querying agent is not aware of DNSSEC. - - If a query arrives at a vDNS64 device with the CD bit set, it is an - indication that the querying agent wants all the validation data so - it can do checking itself. By local policy, vDNS64 could still - - - -Bagnulo, et al. Expires April 22, 2010 [Page 6] - -Internet-Draft DNS64 October 2009 - - - validate, but it must return all data to the querying agent anyway. - - Here are the possible cases: - - 1. A security-oblivious DNS64 node receives a query with the DO bit - clear. In this case, DNSSEC is not a concern, because the - querying agent does not understand DNSSEC responses. - - 2. A security-oblivious DNS64 node receives a query with the DO bit - set, and the CD bit clear. This is just like the case of a non- - DNS64 case: the server doesn't support it, so the querying agent - is out of luck. - - 3. A security-aware and non-validating DNS64 node receives a query - with the DO bit set and the CD bit clear. Such a resolver is not - validating responses, likely due to local policy (see [RFC4035], - section 4.2). For that reason, this case amounts to the same as - the previous case, and no validation happens. - - 4. A security-aware and non-validating DNS64 node receives a query - with the DO bit set and the CD bit set. In this case, the - resolver is supposed to pass on all the data it gets to the query - initiator (see section 3.2.2 of [RFC4035]). This case will be - problematic with DNS64. If the DNS64 server modifies the record, - the client will get the data back and try to validate it, and the - data will be invalid as far as the client is concerned. - - 5. A security-aware and validating DNS64 node receives a query with - the DO bit clear and CD clear. In this case, the resolver - validates the data. If it fails, it returns RCODE 2 (SERVFAIL); - otherwise, it returns the answer. This is the ideal case for - vDNS64. The resolver validates the data, and then synthesizes - the new record and passes that to the client. The client, which - is presumably not validating (else it would have set DO and CD), - cannot tell that DNS64 is involved. - - 6. A security-aware and validating DNS64 node receives a query with - the DO bit set and CD clear. In principle, this ought to work - like the previous case, except that the resolver should also set - the AD bit on the response. - - 7. A security-aware and validating DNS64 node receives a query with - the DO bit set and CD set. This is effectively the same as the - case where a security-aware and non-validating recursive resolver - receives a similar query, and the same thing will happen: the - downstream validator will mark the data as invalid if DNS64 has - performed synthesis. - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 7] - -Internet-Draft DNS64 October 2009 - - -4. Terminology - - This section provides definitions for the special terms used in the - document. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - - Authoritative server: A DNS server that can answer authoritatively a - given DNS question. - - DNS64: A logical function that synthesizes DNS resource records (e.g - AAAA records containing IPv6 addresses) from DNS resource records - actually contained in the global DNS (e.g. A records containing - IPv4 addresses). - - DNS64 recursor: A recursive resolver that provides the DNS64 - functionality as part of its operation. - - Recursive resolver: A DNS server that accepts requests from one - resolver, and asks another resolver for the answer on behalf of - the first resolver. In the context of this document, "the - recursive resolver" means a recursive resolver immediately next in - the DNS resolution chain from an end point. The end point usually - has only a stub resolver available.[[anchor5: I can't actually - remember why we needed the sentences following "In the context of - this document. . ." Unless someone has a reason, I'll take it - out. --ajs@shinkuro.com]] - - Synthetic RR: A DNS resource record (RR) that is not contained in - any zone data file, but has been synthesized from other RRs. An - example is a synthetic AAAA record created from an A record. - - Stub resolver: A resolver with minimum functionality, typically for - use in end points that depend on a recursive resolver. Most end - points on the Internet as of this writing use stub - resolvers.[[anchor6: Do we need this in the document? I don't - think so. 1034 defines this term. --ajs@shinkuro.com]] - - IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4 - packets and vice-versa. It is only required that the - communication initiated from the IPv6 side be supported. - - For a detailed understanding of this document, the reader should also - be familiar with DNS terminology from [RFC1034],[RFC1035] and current - NAT terminology from [RFC4787]. Some parts of this document assume - familiarity with the terminology of the DNS security extensions - - - -Bagnulo, et al. Expires April 22, 2010 [Page 8] - -Internet-Draft DNS64 October 2009 - - - outlined in [RFC4035]. - - -5. DNS64 Normative Specification - - A DNS64 is a logical function that synthesizes AAAA records from A - records. The DNS64 function may be implemented in a stub resolver, - in a recursive resolver, or in an authoritative name server. - - The implementation SHOULD support mapping of IPv4 address ranges to - separate IPv6 prefixes for AAAA record synthesis. This allows - handling of special use IPv4 addresses [I-D.iana-rfc3330bis]. - Multicast address handling is further specified in - [I-D.venaas-behave-mcast46]. - -5.1. Resolving AAAA queries and the answer section - - When the DNS64 receives a query for RRs of type AAAA and class IN, it - first attempts to retrieve non-synthetic RRs of this type and class, - either by performing a query or, in the case of an authoritative - server, by examining its own results. - -5.1.1. The answer when there is AAAA data available - - If the query results in one or more AAAA records in the answer - section, the result is returned to the requesting client as per - normal DNS semantics (except in the case where the AAAA falls in the - ::ffff/96 network; see below for treatment of that network). In this - case, DNS64 SHOULD NOT include synthetic AAAA RRs in the response - (see Appendix B for an analysis of the motivations for and the - implications of not complying with this recommendation). By default - DNS64 implementations MUST NOT synthesize AAAA RRs when real AAAA RRs - exist. - -5.1.2. The answer when there is an error - - If the query results in a response with an error code other than 0, - the result is handled according to normal DNS operation -- that is, - either the resolver tries again using a different server from the - authoritative NS RRSet, or it returns the error to the client. This - stage is still prior to any synthesis having happened, so a response - to be returned to the client does not need any special assembly than - would usually happen in DNS operation. - -5.1.3. Data for the answer when performing synthesis - - If the query results in no error but an empty answer section in the - response, the DNS64 resolver attempts to retrieve A records for the - - - -Bagnulo, et al. Expires April 22, 2010 [Page 9] - -Internet-Draft DNS64 October 2009 - - - name in question. If this new A RR query results in an empty answer - or in an error, then the empty result or error is used as the basis - for the answer returned to the querying client. (Transient errors - may result in retrying the query, depening on the operation of the - resolver; this is just as in Section 5.1.2.) If instead the query - results in one or more A RRs, the DNS64 synthesizes AAAA RRs based on - the A RRs according to the procedure outlined in Section 5.1.4. The - DNS64 resolver then returns the synthesized AAAA records in the - answer section to the client, removing the A records that form the - basis of the synthesis. - - As an exception to the general rule about always returning the AAAA - records if they are returned in the answer, AAAA records with - addresses in the ::ffff/96 network are treated just like the case - where there is neither an error nor an empty answer section. This is - because a real IPv6-only node will not be any more able to reach the - addresses in ::ffff/96 than it is able to reach an IPv4 address - without assistance. An implementation MAY use the address in - ::ffff/96 as the basis of synthesis without querying for an A record, - by using the last 32 bits of the address provided in the AAAA record. - [[anchor10: I changed this to say "neither. . .nor" because the - previous version suggested that it would return the error-or-empty- - answer to the querying client, and that can't be right. Correct? - --ajs@shinkuro.com]] - -5.1.4. Performing the synthesis - - A synthetic AAAA record is created from an A record as follows: - - o The NAME field is set to the NAME field from the A record - - o The TYPE field is set to 28 (AAAA) - - o The CLASS field is set to 1 (IN) - - o The TTL field is set to the minimum of the TTL of the original A - RR and the SOA RR for the queried domain. (Note that in order to - obtain the TTL of the SOA RR the DNS64 does not need to perform a - new query, but it can remember the TTL from the SOA RR in the - negative response to the AAAA query). - - o The RDLENGTH field is set to 16 - - o The RDATA field is set to the IPv6 representation of the IPv4 - address from the RDATA field of the A record. The DNS64 SHOULD - check each A RR against IPv4 address ranges and select the - corresponding IPv6 prefix to use in synthesizing the AAAA RR. See - Section 5.2 for discussion of the algorithms to be used in - - - -Bagnulo, et al. Expires April 22, 2010 [Page 10] - -Internet-Draft DNS64 October 2009 - - - effecting the transformation. - -5.1.5. Querying in parallel - - DNS64 MAY perform the query for the AAAA RR and for the A RR in - parallel, in order to minimize the delay. However, this would result - in performing unnecessary A RR queries in the case no AAAA RR - synthesis is required. A possible trade-off would be to perform them - sequentially but with a very short interval between them, so if we - obtain a fast reply, we avoid doing the additional query. (Note that - this discussion is relevant only if the DNS64 function needs to - perform external queries to fetch the RR. If the needed RR - information is available locally, as in the case of an authoritative - server, the issue is no longer relevant.) - -5.2. Generation of the IPv6 representations of IPv4 addresses - - DNS64 supports multiple algorithms for the generation of the IPv6 - representation of an IPv4 address. The constraints imposed on the - generation algorithms are the following: - - The same algorithm to create an IPv6 address from an IPv4 address - MUST be used by both the DNS64 to create the IPv6 address to be - returned in the synthetic AAAA RR from the IPv4 address contained - in original A RR, and by the IPv6/IPv4 translator to create the - IPv6 address to be included in the destination address field of - the outgoing IPv6 packets from the IPv4 address included in the - destination address field of the incoming IPv4 packet. - - The algorithm MUST be reversible, i.e. it MUST be possible to - extract the original IPv4 address from the IPv6 representation. - - The input for the algorithm MUST be limited to the IPv4 address, - the IPv6 prefix (denoted Pref64::/n) used in the IPv6 - representations and optionally a set of stable parameters that are - configured in the DNS64 (such as fixed string to be used as a - suffix). - - If we note n the length of the prefix Pref64::/n, then n MUST - the less or equal than 96. If a Pref64::/n is configured - through any means in the DNS64 (such as manually configured, or - other automatic mean not specified in this document), the - default algorithm MUST use this prefix. If no prefix is - available, the algorithm MUST use the Well-Known prefix TBD1 - defined in [I-D.thaler-behave-translator-addressing] - - [[anchor12: Note in document: TBD1 in the passage above is to be - substituted by whatever prefix is assigned by IANA to be the well- - - - -Bagnulo, et al. Expires April 22, 2010 [Page 11] - -Internet-Draft DNS64 October 2009 - - - known prefix.]] - - DNS64 MUST support the following algorithms for generating IPv6 - representations of IPv4 addresses defined in - [I-D.thaler-behave-translator-addressing]: - - Zero-Pad And Embed, defined in section 3.2.3 of - [I-D.thaler-behave-translator-addressing] - - Compensation-Pad And Embed, defined in section of 3.2.4 of - [I-D.thaler-behave-translator-addressing] - - Embed And Zero-Pad, defined in section of 3.2.5 of - [I-D.thaler-behave-translator-addressing] - - Preconfigured Mapping Table, defined in section of 3.2.6 of - [I-D.thaler-behave-translator-addressing] - - The default algorithm used by DNS64 must be Embed and Zero-Pad. - While the normative description of the algorithms is provided in - [I-D.thaler-behave-translator-addressing], an sample description of - the algorithm and its application to different scenarios is provided - in Appendix A for illustration purposes. - -5.3. Handling other RRs - -5.3.1. PTR queries - - If a DNS64 nameserver receives a PTR query for a record in the - IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, - reverse the address portion of the QNAME according to the encoding - scheme outlined in section 2.5 of [RFC3596] , and examine the - resulting address to see whether its prefix matches the locally- - configured Pref64::/n. There are two alternatives for a DNS64 - nameserver to respond to such PTR queries. A DNS64 node MUST provide - one of these, and SHOULD NOT provide both at the same time unless - different IP6.ARPA zones require answers of different sorts. - - The first option is for the DNS64 nameserver to respond - authoritatively for its prefixes. If the address prefix matches any - Pref64::/n used in the site, either a LIR prefix or a well-known - prefix used for NAT64 as defined in - [I-D.thaler-behave-translator-addressing], then the DNS64 server MAY - answer the query using locally-appropriate RDATA. The DNS64 server - MAY use the same RDATA for all answers. Note that the requirement is - to match any Pref64::/n used at the site, and not merely the locally- - configured Pref64::/n. This is because end clients could ask for a - PTR record matching an address received through a different (site- - - - -Bagnulo, et al. Expires April 22, 2010 [Page 12] - -Internet-Draft DNS64 October 2009 - - - provided) DNS64, and if this strategy is in effect, those queries - should never be sent to the global DNS. The advantage of this - strategy is that it makes plain to the querying client that the - prefix is one operated by the DNS64 site, and that the answers the - client is getting are generated by the DNS64. The disadvantage is - that any useful reverse-tree information that might be in the global - DNS is unavailable to the clients querying the DNS64. - - The second option is for the DNS64 nameserver to synthesize a CNAME - mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA - name. The rest of the response would be the normal DNS processing. - The CNAME can be signed on the fly if need be. The advantage of this - approach is that any useful information in the reverse tree is - available to the querying client. The disadvantage is that it adds - additional load to the DNS64 (because CNAMEs have to be synthesized - for each PTR query that matches the Pref64::/n), and that it may - require signing on the fly. [[anchor15: what are we supposed to do - here when the in-addr.arpa zone is unmaintained, as it may be. If - there is no data at the target name, then we'll get a CNAME with a - map to an empty namespace, I think? Isn't that bad? - --ajs@shinkuro.com]] - - If the address prefix does not match any of the Pref64::/n, then the - DNS64 server MUST process the query as though it were any other query - -- i.e. a recursive nameserver MUST attempt to resolve the query as - though it were any other (non-A/AAAA) query, and an authoritative - server MUST respond authoritatively or with a referral, as - appropriate. - -5.3.2. Handling the additional section - - DNS64 synthesis MUST NOT be performed on any records in the - additional section of synthesized answers. The DNS64 MUST pass the - additional section unchanged. - - [[anchor16: We had some discussion, as an alternative to the above, - of allowing the DNS64 to truncate the additional section completely, - on the grounds that the additional section could break mixed-mode - iterative/forwarding resolvers that happen to end up behind DNS64. - Nobody else seemed to like that plan, so I haven't included it. - --ajs@shinkuro.com]] - -5.3.3. Other records - - If the DNS64 is in recursive resolver mode, then it SHOULD also serve - the zones specified in [I-D.ietf-dnsop-default-local-zones], rather - than forwarding those queries elsewhere to be handled. - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 13] - -Internet-Draft DNS64 October 2009 - - - All other RRs MUST be returned unchanged. - -5.4. Assembling a synthesized response to a AAAA query - - The DNS64 uses different pieces of data to build the response - returned to the querying client. - - The query that is used as the basis for synthesis results either in - an error, an answer that can be used as a basis for synthesis, or an - empty (authoritative) answer. If there is an empty answer, then the - DNS64 responds to the original querying client with the answer the - DNS64 received to the original AAAA query. Otherwise, the response - is assembled as follows. - - The header fields are set according to the usual rules for recursive - or authoritative servers, depending on the role that the DNS64 is - serving. The question section is copied from the original AAAA - query. The answer section is populated according to the rules in - Section 5.1.4. The authority section is copied from the response to - the A query that the DNS64 performed. The additional section is - populated according to the rules in Section 5.3.2. - - [[anchor18: The cross-reference to how to do the additional section - can be removed, and replaced by "copied from the response to the A - query that the DNS64 performed" if we don't want to allow the DNS64 - to truncate the additional section. See the note above. If I hear - no more feedback on this topic, then I'll make this change in the - next version. --ajs@shinkuro.com]] - -5.5. DNSSEC processing: DNS64 in recursive server mode - - We consider the case where the recursive server that is performing - DNS64 also has a local policy to validate the answers according to - the procedures outlined in [RFC4035] Section 5. We call this general - case vDNS64. - - The vDNS64 uses the presence of the DO and CD bits to make some - decisions about what the query originator needs, and can react - accordingly: - - 1. If CD is not set and DO is not set, vDNS64 SHOULD perform - validation and do synthesis as needed. - - 2. If CD is not set and DO is set, then vDNS64 SHOULD perform - validation. Whenever vDNS64 performs validation, it MUST - validate the negative answer for AAAA queries before proceeding - to query for A records for the same name, in order to be sure - that there is not a legitimate AAAA record on the Internet. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 14] - -Internet-Draft DNS64 October 2009 - - - Failing to observe this step would allow an attacker to use DNS64 - as a mechanism to circumvent DNSSEC. If the negative response - validates, and the response to the A query validates, then the - vDNS64 MAY perform synthesis and SHOULD set the AD bit in the - answer to the client. This is acceptable, because [RFC4035], - section 3.2.3 says that the AD bit is set by the name server side - of a security-aware recursive name server if and only if it - considers all the RRSets in the Answer and Authority sections to - be authentic. In this case, the name server has reason to - believe the RRSets are all authentic, so it SHOULD set the AD - bit. If the data does not validate, the vDNS64 MUST respond with - RCODE=2 (server failure). - A security-aware end point might take the presence of the AD bit - as an indication that the data is valid, and may pass the DNS - (and DNSSEC) data to an application. If the application attempts - to validate the synthesized data, of course, the validation will - fail. One could argue therefore that this approach is not - desirable. But security aware stub resolvers MUST NOT place any - reliance on data received from resolvers and validated on their - behalf without certain criteria established by [RFC4035], section - 4.9.3. An application that wants to perform validation on its - own should use the CD bit. - - 3. If the CD bit is set and DO is set, then vDNS64 MAY perform - validation, but MUST NOT perform synthesis. It MUST hand the - data back to the query initiator, just like a regular recursive - resolver, and depend on the client to do the validation and the - synthesis itself. - The disadvantage to this approach is that an end point that is - translation-oblivious but security-aware and validating will not - be able to use the DNS64 functionality. In this case, the end - point will not have the desired benefit of NAT64. In effect, - this strategy means that any end point that wishes to do - validation in a NAT64 context must be upgraded to be translation- - aware as well. - -5.6. DNS64 and multihoming - - Synthetic AAAA records may be constructed on the basis of the network - context in which they were constructed. Therefore, a synthetic AAAA - received from one interface MUST NOT be used to resolve hosts via - another network interface. [[anchor21: This seems to be the result of - the discussion on-list starting with message id 18034D4D7FE9AE48BF19A - B1B0EF2729F3EF0E69687@NOK-EUMSG-01.mgdnok.nokia.com, but it's pretty - strange when stated baldly. In particular, how is the multi-homed - host supposed to know that a given AAAA is synthetic? - --ajs@shinkuro.com]] - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 15] - -Internet-Draft DNS64 October 2009 - - -6. Deployment notes - - While DNS64 is intended to be part of a strategy for aiding IPv6 - deployment in an internetworking environment with some IPv4-only and - IPv6-only networks, it is important to realise that it is - incompatible with some things that may be deployed in an IPv4-only or - dual-stack context. - -6.1. DNS resolvers and DNS64 - - Full-service resolvers that are unaware of the DNS64 function can be - (mis)configured to act as mixed-mode iterative and forwarding - resolvers. In a native-IPv4 context, this sort of configuration may - appear to work. It is impossible to make it work properly without it - being aware of the DNS64 function, because it will likely at some - point obtain IPv4-only glue records and attempt to use them for - resolution. The result that is returned will contain only A records, - and without the ability to perform the DNS64 function the resolver - will simply be unable to answer the necessary AAAA queries. - -6.2. DNSSEC validators and DNS64 - - Existing DNSSEC validators (i.e. that are unaware of DNS64) will - reject all the data that comes from the DNS64 as having been tampered - with. If it is necessary to have validation behind the DNS64, then - the validator must know how to perform the DNS64 function itself. - Alternatively, the validating host may establish a trusted connection - with the DNS64, and allow the DNS64 to do all validation on its - behalf. - - -7. Security Considerations - - See the discussion on the usage of DNSSEC and DNS64 described in the - document. - - -8. Contributors - - Dave Thaler - - Microsoft - - dthaler@windows.microsoft.com - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 16] - -Internet-Draft DNS64 October 2009 - - -9. Acknowledgements - - This draft contains the result of discussions involving many people, - including the participants of the IETF BEHAVE Working Group. The - following IETF participants made specific contributions to parts of - the text, and their help is gratefully acknowledged: Mark Andrews, - Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Marc Blanchet, - Cameron Byrne, Brian Carpenter, Hui Deng, Francis Dupont, Ed - Jankiewicz, Peter Koch, Suresh Krishnan, Ed Lewis, Xing Li, Matthijs - Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki - Soini, Dave Thaler, Mark Townsley, Stig Venaas, Magnus Westerlund, - Florian Weimer, Dan Wing, Xu Xiaohu. - - Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by - Trilogy, a research project supported by the European Commission - under its Seventh Framework Program. - - -10. References - -10.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm - (SIIT)", RFC 2765, February 2000. - - [RFC4787] Audet, F. and C. Jennings, "Network Address Translation - (NAT) Behavioral Requirements for Unicast UDP", BCP 127, - RFC 4787, January 2007. - - [I-D.ietf-behave-tcp] - Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. - Srisuresh, "NAT Behavioral Requirements for TCP", - draft-ietf-behave-tcp-08 (work in progress), - - - -Bagnulo, et al. Expires April 22, 2010 [Page 17] - -Internet-Draft DNS64 October 2009 - - - September 2008. - - [I-D.ietf-behave-nat-icmp] - Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT - Behavioral Requirements for ICMP protocol", - draft-ietf-behave-nat-icmp-12 (work in progress), - January 2009. - - [I-D.thaler-behave-translator-addressing] - Thaler, D., "IPv6 Addressing of IPv6/IPv4 Translators", - draft-thaler-behave-translator-addressing-00 (work in - progress), July 2009. - -10.2. Informative References - - [I-D.bagnulo-behave-nat64] - Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network - Address and Protocol Translation from IPv6 Clients to IPv4 - Servers", draft-bagnulo-behave-nat64-03 (work in - progress), March 2009. - - [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address - Translation - Protocol Translation (NAT-PT)", RFC 2766, - February 2000. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security - Considerations for IP Fragment Filtering", RFC 1858, - October 1995. - - [RFC3128] Miller, I., "Protection Against a Variant of the Tiny - Fragment Attack (RFC 1858)", RFC 3128, June 2001. - - [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network - Address Translator (Traditional NAT)", RFC 3022, - January 2001. - - [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, February 2003. - - [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, - "DNS Extensions to Support IP Version 6", RFC 3596, - October 2003. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 18] - -Internet-Draft DNS64 October 2009 - - - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network - Address Translator - Protocol Translator (NAT-PT) to - Historic Status", RFC 4966, July 2007. - - [I-D.iana-rfc3330bis] - Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", - draft-iana-rfc3330bis-06 (work in progress), - February 2009. - - [I-D.ietf-mmusic-ice] - Rosenberg, J., "Interactive Connectivity Establishment - (ICE): A Protocol for Network Address Translator (NAT) - Traversal for Offer/Answer Protocols", - draft-ietf-mmusic-ice-19 (work in progress), October 2007. - - [I-D.ietf-6man-addr-select-sol] - Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, - "Solution approaches for address-selection problems", - draft-ietf-6man-addr-select-sol-01 (work in progress), - June 2008. - - [RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of - Managed Objects for Synchronous Optical Network (SONET) - Linear Automatic Protection Switching (APS) - Architectures", RFC 3498, March 2003. - - [I-D.wing-behave-learn-prefix] - Wing, D., Wang, X., and X. Xu, "Learning the IPv6 Prefix - of an IPv6/IPv4 Translator", - draft-wing-behave-learn-prefix-02 (work in progress), - May 2009. - - [I-D.miyata-behave-prefix64] - Miyata, H. and M. Bagnulo, "PREFIX64 Comparison", - draft-miyata-behave-prefix64-02 (work in progress), - March 2009. - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 19] - -Internet-Draft DNS64 October 2009 - - - [I-D.venaas-behave-mcast46] - Venaas, S., "An IPv4 - IPv6 multicast translator", - draft-venaas-behave-mcast46-00 (work in progress), - December 2008. - - [I-D.ietf-dnsop-default-local-zones] - Andrews, M., "Locally-served DNS Zones", - draft-ietf-dnsop-default-local-zones-08 (work in - progress), February 2009. - - -Appendix A. Deployment scenarios and examples - - In this section, we first provide a description of the default - address transformation algorithm and then we walk through some sample - scenarios that are expected to be common deployment cases. It should - be noted that is provided for illustrative purposes and this section - is not normative. The normative definition of DNS64 is provided in - Section 5 and the normative definition of the address transformation - algorithm is provided in [I-D.thaler-behave-translator-addressing]. - - There are two main different setups where DNS64 is expected to be - used (other setups are possible as well, but these two are the main - ones identified at the time of this writing). - - One possible setup that is expected to be common is the case of an - end site or an ISP that is providing IPv6-only connectivity or - connectivity to IPv6-only hosts that wants to allow the - communication from these IPv6-only connected hosts to the IPv4 - Internet. This case is called An-IPv6-network-to-IPv4-Internet. - In this case, the IPv6/IPv4 Translator is used to connect the end - site or the ISP to the IPv4 Internet and the DNS64 function is - provided by the end site or the ISP. - - The other possible setup that is expected is an IPv4 site that - wants that its IPv4 servers to be reachable from the IPv6 - Internet. This case is called IPv6-Internet-to-an-IPv4-network. - It should be noted that the IPv4 addresses used in the IPv4 site - can be either public or private. In this case, the IPv6/IPv4 - Translator is used to connect the IPv4 end site to the IPv6 - Internet and the DNS64 function is provided by the end site - itself. - - In this section we illustrate how the DNS64 behaves in the different - scenarios that are expected to be common. We consider then 3 - possible scenarios, namely: - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 20] - -Internet-Draft DNS64 October 2009 - - - 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server - mode - - 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub- - resolver mode - - 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server - mode - - The notation used is the following: upper case letters are IPv4 - addresses; upper case letters with a prime(') are IPv6 addresses; - lower case letters are ports; prefixes are indicated by "P::X", which - is an IPv6 address built from an IPv4 address X by adding the prefix - P, mappings are indicated as "(X,x) <--> (Y',y)". - -A.1. Embed and Zero-Pad algorithm description - - In this section we describe the default algorithm for the generation - of IPv6 address from IPv4 address to be implemented in the DNS64. - - The only parameter required by the default algorithm is an IPv6 - prefix. This prefix is used to map IPv4 addresses into IPv6 - addresses, and is denoted Pref64. If we note n the length of the - prefix Pref64, then n must the less or equal than 96. If an Pref64 - is configured through any means in the DNS64 (such as manually - configured, or other automatic mean not specified in this document), - the default algorithm must use this prefix. If no prefix is - available the algorithm must use the Well-Know prefix (include here - the prefix to be assigned by IANA) defined in - [I-D.thaler-behave-translator-addressing] - - The input for the algorithm are: - - The IPv4 address: X - - The IPv6 prefix: Pref64::/n - - The IPv6 address is generated by concatenating the prefix Pref64::/n, - the IPv4 address X and optionally (in case n is strictly smaller than - 96) an all-zero suffix. So, the resulting IPv6 address would be - Pref64:X:: - - Reverse algorithm - - We next describe the reverse algorithm of the algorithm described in - the previous section. This algorithm allows to generate and IPv4 - address from an IPv6 address. This reverse algorithm is NOT - implemented by the DNS64 but it is implemented in the IPv6/IPv4 - - - -Bagnulo, et al. Expires April 22, 2010 [Page 21] - -Internet-Draft DNS64 October 2009 - - - translator that is serving the same domain the DNS64. - - The only parameter required by the default algorithm is an IPv6 - prefix. This prefix is the one originally used to map IPv4 addresses - into IPv6 addresses, and is denoted Pref64. - - The input for the algorithm are: - - The IPv6 address: X' - - The IPv6 prefix: Pref64::/n - - First, the algorithm checks that the fist n bits of the IPv6 address - X' match with the prefix Pref64::/n i.e. verifies that Pref64::/n = - X'/n. - - If this is not the case, the algorithm ends and no IPv4 address is - generated. - - If the verification is successful, then the bits between the n+1 - and the n+32 of the IPv6 address X' are extracted to form the IPv4 - address. - -A.2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server - mode - - In this example, we consider an IPv6 node located in an IPv6-only - site that initiates a communication to an IPv4 node located in the - IPv4 Internet. - - The scenario for this case is depicted in the following figure: - - - +---------------------------------------+ +-----------+ - |IPv6 site +-------------+ |IP Addr: | | - | +----+ | Name server | +-------+ T | IPv4 | - | | H1 | | with DNS64 | |64Trans|------| Internet | - | +----+ +-------------+ +-------+ +-----------+ - | |IP addr: Y' | | | |IP addr: X - | --------------------------------- | +----+ - +---------------------------------------+ | H2 | - +----+ - - The figure shows an IPv6 node H1 which has an IPv6 address Y' and an - IPv4 node H2 with IPv4 address X. - - A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 - Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n) - - - -Bagnulo, et al. Expires April 22, 2010 [Page 22] - -Internet-Draft DNS64 October 2009 - - - an IPv4 address T assigned to its IPv4 interface. - - The other element involved is the local name server. The name server - is a dual-stack node, so that H1 can contact it via IPv6, while it - can contact IPv4-only name servers via IPv4. - - The local name server needs to know the prefix assigned to the local - IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example, - we assume it learns this through manual configuration. - - For this example, assume the typical DNS situation where IPv6 hosts - have only stub resolvers, and always query a name server that - performs recursive lookups (henceforth called "the recursive - nameserver"). - - The steps by which H1 establishes communication with H2 are: - - 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS - query for an AAAA record for H2 to the recursive name server. - The recursive name server implements DNS64 functionality. - - 2. The recursive name server resolves the query, and discovers that - there are no AAAA records for H2. - - 3. The recursive name server queries for an A record for H2 and gets - back an A record containing the IPv4 address X. The name server - then synthesizes an AAAA record. The IPv6 address in the AAAA - record contains the prefix assigned to the IPv6/IPv4 Translator - in the upper n bits then the IPv4 address X and then an all-zero - padding i.e. the resulting IPv6 address is Pref64:X:: - - 4. H1 receives the synthetic AAAA record and sends a packet towards - H2. The packet is sent from a source transport address of (Y',y) - to a destination transport address of (Pref64:X::,x), where y and - x are ports chosen by H2. - - 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 - Translator and the subsequent communication flows by means of the - IPv6/IPv4 Translator mechanisms. - -A.3. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-resolver - mode - - The scenario for this case is depicted in the following figure: - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 23] - -Internet-Draft DNS64 October 2009 - - - +---------------------------------------+ +-----------+ - |IPv6 site +-------+ |IP addr: | | - | +---------------+ | Name | +-------+ T | IPv4 | - | | H1 with DNS64 | | Server| |64Trans|------| Internet | - | +---------------+ +-------+ +-------+ +-----------+ - | |IP addr: Y' | | | |IP addr: X - | --------------------------------- | +----+ - +---------------------------------------+ | H2 | - +----+ - - The figure shows an IPv6 node H1 which has an IPv6 address Y' and an - IPv4 node H2 with IPv4 address X. Node H1 is implementing the DNS64 - function. - - A IPv6/IPv4 Translator connects the IPv6 network to the IPv4 - Internet. This IPv6/IPv4 Translator has a prefix (called Pref64::/n) - and an IPv4 address T assigned to its IPv4 interface. - - H1 needs to know the prefix assigned to the local IPv6/IPv4 - Translator (Pref64::/n). For the purpose of this example, we assume - it learns this through manual configuration. - - Also shown is a name server. For the purpose of this example, we - assume that the name server is a dual-stack node, so that H1 can - contact it via IPv6, while it can contact IPv4-only name servers via - IPv4. - - For this example, assume the typical situation where IPv6 hosts have - only stub resolvers and always query a name server that provides - recursive lookups (henceforth called "the recursive name server"). - The recursive name server does not perform the DNS64 function. - - The steps by which H1 establishes communication with H2 are: - - 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS - query for a AAAA record for H2 to the recursive name server. - - 2. The recursive DNS server resolves the query, and returns the - answer to H1. Because there are no AAAA records in the global - DNS for H2, the answer is empty. - - 3. The stub resolver at H1 then queries for an A record for H2 and - gets back an A record containing the IPv4 address X. The DNS64 - function within H1 then synthesizes a AAAA record. The IPv6 - address in the AAAA record contains the prefix assigned to the - IPv6/IPv4 Translator in the upper n bits, then the IPv4 address X - and then an all-zero padding i.e. the resulting IPv6 address is - Pref64:X::. - - - -Bagnulo, et al. Expires April 22, 2010 [Page 24] - -Internet-Draft DNS64 October 2009 - - - 4. H1 sends a packet towards H2. The packet is sent from a source - transport address of (Y',y) to a destination transport address of - (Pref64:X::,x), where y and x are ports chosen by H2. - - 5. The packet is routed to the IPv6 interface of the IPv6/IPv4 - Translator and the subsequent communication flows using the IPv6/ - IPv4 Translator mechanisms. - -A.4. IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS server mode - - In this example, we consider an IPv6 node located in the IPv6 - Internet site that initiates a communication to a IPv4 node located - in the IPv4 site. - - This scenario can be addressed without using any form of DNS64 - function. This is so because it is possible to assign a fixed IPv6 - address to each of the IPv4 servers. Such an IPv6 address would be - constructed as the Pref64::/n concatenated with the IPv4 address of - the IPv4 server and an all-zero padding. Note that the IPv4 address - can be a public or a private address; the latter does not present any - additional difficulty, since the LIR prefix must be used a Pref64 (in - this scenario the usage of the WK prefix is not supported). Once - these IPv6 addresses have been assigned to represent the IPv4 servers - in the IPv6 Internet, real AAAA RRs containing these addresses can be - published in the DNS under the site's domain. This is the - recommended approach to handle this scenario, because it does not - involve synthesizing AAAA records at the time of query. Such a - configuration is easier to troubleshoot in the event of problems, - because it always provides the same answer to every query. - - However, there are some more dynamic scenarios, where synthesizing - AAAA RRs in this setup may be needed. In particular, when DNS Update - [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4 - servers, there are two options: One option is to modify the server - that receives the dynamic DNS updates. That would normally be the - authoritative server for the zone. So the authoritative zone would - have normal AAAA RRs that are synthesized as dynamic updates occur. - The other option is modify the authoritative server to generate - synthetic AAAA records for a zone, possibly based on additional - constraints, upon the receipt of a DNS query for the AAAA RR. The - first option -- in which the AAAA is synthesized when the DNS update - message is received, and the data published in the relevant zone -- - is recommended over the second option (i.e. the synthesis upon - receipt of the AAAA DNS query). This is because it is usually easier - to solve problems of misconfiguration and so on when the DNS - responses are not being generated dynamically. For completeness, the - DNS64 behavior that we describe in this section covers the case of - synthesizing the AAAA RR when the DNS query arrives. Nevertheless, - - - -Bagnulo, et al. Expires April 22, 2010 [Page 25] - -Internet-Draft DNS64 October 2009 - - - such a configuration is NOT RECOMMENDED. Troubleshooting - configurations that change the data depending on the query they - receive is notoriously hard, and the IPv4/IPv6 translation scenario - is complicated enough without adding additional opportunities for - possible malfunction. - - The scenario for this case is depicted in the following figure: - - - +-----------+ +----------------------------------------+ - | | | IPv4 site +-------------+ | - | IPv6 | +-------+ +----+ | Name server | | - | Internet |------|64Trans| | H2 | | with DNS64 | | - +-----------+ +-------+ +----+ +-------------+ | - |IP addr: Y' | | |IP addr: X | | - +----+ | ----------------------------------- | - | H1 | +----------------------------------------+ - +----+ - - The figure shows an IPv6 node H1 which has an IPv6 address Y' and an - IPv4 node H2 with IPv4 address X. - - A IPv6/IPv4 Translator connects the IPv4 network to the IPv6 - Internet. This IPv6/IPv4 Translator has a prefix (called - Pref64::/n). - - Also shown is the authoritative name server for the local domain with - DNS64 functionality. For the purpose of this example, we assume that - the name server is a dual-stack node, so that H1 or a recursive - resolver acting on the request of H1 can contact it via IPv6, while - it can be contacted by IPv4-only nodes to receive dynamic DNS updates - via IPv4. - - The local name server needs to know the prefix assigned to the local - IPv6/IPv4 Translator (Pref64::/n). For the purpose of this example, - we assume it learns this through manual configuration. - - The steps by which H1 establishes communication with H2 are: - - 1. H1 does a DNS lookup for FQDN(H2). H1 does this by sending a DNS - query for an AAAA record for H2. The query is eventually - forwarded to the server in the IPv4 site. - - 2. The local DNS server resolves the query (locally), and discovers - that there are no AAAA records for H2. - - 3. The name server verifies that FQDN(H2) and its A RR are among - those that the local policy defines as allowed to generate a AAAA - - - -Bagnulo, et al. Expires April 22, 2010 [Page 26] - -Internet-Draft DNS64 October 2009 - - - RR from. If that is the case, the name server synthesizes an - AAAA record from the A RR and the relevant Pref64::/n. The IPv6 - address in the AAAA record contains the prefix assigned to the - IPv6/IPv4 Translator in the first n bits and the IPv4 address X - and then an all-zero padding. - - 4. H1 receives the synthetic AAAA record and sends a packet towards - H2. The packet is sent from a source transport address of (Y',y) - to a destination transport address of (Pref64:X::,x), where y and - x are ports chosen by H2. - - 5. The packet is routed through the IPv6 Internet to the IPv6 - interface of the IPv6/IPv4 Translator and the communication flows - using the IPv6/IPv4 Translator mechanisms. - - -Appendix B. Motivations and Implications of synthesizing AAAA RR when - real AAAA RR exists - - The motivation for synthesizing AAAA RR when a real AAAA RR exists is - to support the following scenario: - - An IPv4-only server application (e.g. web server software) is - running on a dual-stack host. There may also be dual-stack server - applications also running on the same host. That host has fully - routable IPv4 and IPv6 addresses and hence the authoritative DNS - server has an A and a AAAA record as a result. - - An IPv6-only client (regardless of whether the client application - is IPv6-only, the client stack is IPv6-only, or it only has an - IPv6 address) wants to access the above server. - - The client issues a DNS query to a DNS64 recursor. - - If the DNS64 only generates a synthetic AAAA if there's no real AAAA, - then the communication will fail. Even though there's a real AAAA, - the only way for communication to succeed is with the translated - address. So, in order to support this scenario, the administrator of - a DNS64 service may want to enable the synthesis of AAAA RR even when - real AAAA RR exist. - - The implication of including synthetic AAAA RR when real AAAA RR - exist is that translated connectivity may be preferred over native - connectivity in some cases where the DNS64 is operated in DNS server - mode. - - RFC3484 [RFC3484] rules use longest prefix match to select which is - the preferred destination address to use. So, if the DNS64 recursor - - - -Bagnulo, et al. Expires April 22, 2010 [Page 27] - -Internet-Draft DNS64 October 2009 - - - returns both the synthetic AAAA RR and the real AAAA RR, then if the - DNS64 is operated by the same domain as the initiating host, and a - global unicast prefix (called the LIR prefix as defined in - [I-D.thaler-behave-translator-addressing]) is used, then the - synthetic AAAA RR is likely to be preferred. - - This means that without further configuration: - - In the case of An IPv6 network to the IPv4 internet, the host will - prefer translated connectivity if LIR prefix is used. If the - Well-Known (WK) prefix defined in - [I-D.thaler-behave-translator-addressing] is used, it will - probably prefer native connectivity. - - In the case of the IPv6 Internet to an IPv4 network, it is - possible to bias the selection towards the real AAAA RR if the - DNS64 recursor returns the real AAAA first in the DNS reply, when - the LIR prefix is used (the WK prefix usage is not recommended in - this case) - - In the case of the IPv6 to IPv4 in the same network, for local - destinations (i.e., target hosts inside the local site), it is - likely that the LIR prefix and the destination prefix are the - same, so we can use the order of RR in the DNS reply to bias the - selection through native connectivity. If a WK prefix is used, - the longest prefix match rule will select native connectivity. - - So this option introduces problems in the following cases: - - An IPv6 network to the IPv4 internet with the LIR prefix - - IPv6 to IPv4 in the same network when reaching external - destinations and the LIR prefix is used. - - In any case, the problem can be solved by properly configuring the - RFC3484 [RFC3484] policy table, but this requires effort on the part - of the site operator. - - - - - - - - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 28] - -Internet-Draft DNS64 October 2009 - - -Authors' Addresses - - Marcelo Bagnulo - UC3M - Av. Universidad 30 - Leganes, Madrid 28911 - Spain - - Phone: +34-91-6249500 - Fax: - Email: marcelo@it.uc3m.es - URI: http://www.it.uc3m.es/marcelo - - - Andrew Sullivan - Shinkuro - 4922 Fairmont Avenue, Suite 250 - Bethesda, MD 20814 - USA - - Phone: +1 301 961 3131 - Email: ajs@shinkuro.com - - - Philip Matthews - Unaffiliated - 600 March Road - Ottawa, Ontario - Canada - - Phone: +1 613-592-4343 x224 - Fax: - Email: philip_matthews@magma.ca - URI: - - - Iljitsch van Beijnum - IMDEA Networks - Av. Universidad 30 - Leganes, Madrid 28911 - Spain - - Phone: +34-91-6246245 - Email: iljitsch@muada.com - - - - - - - -Bagnulo, et al. Expires April 22, 2010 [Page 29] - diff --git a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt deleted file mode 100644 index 41ae72ec2eb..00000000000 --- a/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt +++ /dev/null @@ -1,448 +0,0 @@ - - - -DNSEXT R. Bellis -Internet-Draft Nominet UK -Updates: 1035, 1123 October 26, 2009 -(if approved) -Intended status: Standards Track -Expires: April 29, 2010 - - - DNS Transport over TCP - draft-ietf-dnsext-dns-tcp-requirements-01 - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 29, 2010. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - This document updates the requirements for the support of the TCP - - - -Bellis Expires April 29, 2010 [Page 1] - -Internet-Draft DNS Transport over TCP October 2009 - - - protocol for the transport of DNS traffic. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 2. Terminology used in this document . . . . . . . . . . . . . . . 3 - - 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - - 4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4 - - 5. Dormant Connection Handling . . . . . . . . . . . . . . . . . . 5 - - 6. Response re-ordering . . . . . . . . . . . . . . . . . . . . . 6 - - 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 - - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 - - Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7 - - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 - - - - - - - - - - - - - - - - - - - - - - - -Bellis Expires April 29, 2010 [Page 2] - -Internet-Draft DNS Transport over TCP October 2009 - - -1. Introduction - - Most DNS [RFC1035] transactions take place over the UDP [RFC0792] - protocol. The TCP [RFC0793] protocol is used for zone transfers and - is supported by many implementations for the transfer of other - packets which exceed the protocol's original 512 byte packet-size - limit. - - Section 6.1.3.2 of [RFC1123] states: - - DNS resolvers and recursive servers MUST support UDP, and SHOULD - support TCP, for sending (non-zone-transfer) queries. - - However, some implementors have taken the text quoted above to mean - that TCP support is truly optional for typical DNS operation. - - This document normatively updates the core DNS protocol - specifications such that (except in very limited circumstances) - support for the TCP protocol is henceforth REQUIRED. - - -2. Terminology used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -3. Discussion - - In the absence of EDNS0 (see below) the normal behaviour of any DNS - server needing to send a UDP response that exceeds that 512 byte - limit is for the server to truncate the response at the 512 byte - limit and set the TC flag in the response header. When the client - receives such a response it takes the TC flag as notice that it - should retry over TCP instead. - - RFC 1123 also says: - - ... it is also clear that some new DNS record types defined in the - future will contain information exceeding the 512 byte limit that - applies to UDP, and hence will require TCP. Thus, resolvers and - name servers should implement TCP services as a backup to UDP - today, with the knowledge that they will require the TCP service - in the future. - - Existing deployments of DNSSEC [RFC4033] have shown that truncation - at the 512 byte boundary is now commonplace. For example an NXDOMAIN - - - -Bellis Expires April 29, 2010 [Page 3] - -Internet-Draft DNS Transport over TCP October 2009 - - - (RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155] - is almost invariably longer than 512 bytes. - - Since the original core specifications for DNS were written, the - Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced. - These extensions can be used to indicate that the client is prepared - to receive UDP responses longer than 512 bytes. An EDNS0 compatible - server receiving a request from an EDNS0 compatible client may send - UDP packets up to that client's announced buffer size without - truncation. - - However, transport of UDP packets which exceed the size of the path - MTU has been found to be unreliable in some circumstances because of - IP packet fragmentation. Many firewalls routinely block fragmented - IP packets, and some implementations lack the software logic - necessary to reassemble a fragmented datagram. Worse still, some - devices deliberately refuse to handle DNS packets containing EDNS0 - options. Other issues relating to UDP transport and packet size are - discussed in [RFC5625]. - - The MTU most commonly found in the core of the Internet is around - 1500 bytes, and even that limit is routinely exceeded by DNSSEC - signed responses. - - The future that was anticipated in RFC 1123 has arrived, and the only - standardised mechanism which may have resolved the packet size issue - has been found inadequate. - - -4. Transport Protocol Selection - - All DNS implementations MUST support both UDP and TCP transport - protocols, except as set out below. - - On a case by case basis, authoritative DNS server operators MAY elect - to disable DNS transport over TCP if all of the following conditions - are satisfied: - - o the server is authoritative only - o the server does not support AXFR - o all requests and responses are guaranteed to be <= 512 bytes - - A general purpose stub resolver implementation (e.g. an operating - system's DNS resolution library) MUST support TCP since to do - otherwise would limit its interoperability with its own clients and - with upstream servers. - - A proprietary stub resolver implementation MAY omit support for TCP - - - -Bellis Expires April 29, 2010 [Page 4] - -Internet-Draft DNS Transport over TCP October 2009 - - - if it is operating in an environment where truncation can never - occur, or if it is prepared to accept a DNS lookup failure should - truncation occur. - - A recursive resolver or forwarder MUST support TCP so that it does - not prevent long responses from a TCP-capable server from reaching - its TCP-capable clients. - - Regarding the choice of when to use UDP or TCP, RFC 1123 says: - - ... a DNS resolver or server that is sending a non-zone-transfer - query MUST send a UDP query first. - - That requirement is hereby relaxed. A resolver SHOULD send a UDP - query first, but MAY elect to send a TCP query instead if it has good - reason to expect the response would be truncated if it were sent over - UDP (with or without EDNS0) or for other operational reasons. - - -5. Dormant Connection Handling - - Section 4.2.2 of [RFC1035] says: - - If the server needs to close a dormant connection to reclaim - resources, it should wait until the connection has been idle for a - period on the order of two minutes. - - Other more modern protocols (e.g. HTTP [RFC2616]) have support for - persistent TCP connections and operational experience has shown that - long timeouts can easily cause resource exhaustion and poor response - under heavy load. Intentionally opening many connections and leaving - them dormant can trivially create a "denial of service" attack. - - This document therefore RECOMMENDS that the idle period should be of - the order of TBD seconds. - - Servers MAY allow dormant connections to remain open for longer - periods, but for the avoidance of doubt persistent DNS connections - should generally be considered to be as much for the server's benefit - as for the client's. Therefore if the server needs to unilaterally - close a dormant TCP connection it MUST be free to do so whenever - required. - - Further recommendations for the tuning of TCP parameters to allow - higher throughput or improved resiliency against denial of service - attacks are (currently) outside the scope of this document. - - - - - -Bellis Expires April 29, 2010 [Page 5] - -Internet-Draft DNS Transport over TCP October 2009 - - -6. Response re-ordering - - RFC 1035 is ambiguous on the question of whether TCP queries may be - re-ordered - the only relevant text is in Section 4.2.1 which relates - to UDP: - - Queries or their responses may be reordered by the network, or by - processing in name servers, so resolvers should not depend on them - being returned in order. - - For the avoidance of future doubt, this requirement is clarified. - Client resolvers MUST be able to process responses which arrive in a - different order to that in which the requests were sent, regardless - of the transport protocol in use. - - -7. Security Considerations - - Some DNS server operators have expressed concern that wider use of - DNS over TCP will expose them to a higher risk of "denial of service" - attacks. - - Many large authoritative DNS operators including all but one of the - root servers and the vast majority of TLDs already support TCP and - attacks against them are infrequent and very rarely successful. - - Operators of recursive servers should ensure that they only accept - connections from expected clients, and do not accept them from - unknown sources. In the case of UDP traffic this will protect - against reflector attacks [RFC5358] and in the case of TCP traffic it - will prevent an unknown client from exhausting the server's limits on - the number of concurrent connections. - - -8. IANA Considerations - - This document requests no IANA actions. - - -9. References - -9.1. Normative References - - [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, - RFC 792, September 1981. - - [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, - RFC 793, September 1981. - - - -Bellis Expires April 29, 2010 [Page 6] - -Internet-Draft DNS Transport over TCP October 2009 - - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", - RFC 2671, August 1999. - -9.2. Informative References - - [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., - Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext - Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - - [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive - Nameservers in Reflector Attacks", BCP 140, RFC 5358, - October 2008. - - [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", - BCP 152, RFC 5625, August 2009. - - -Appendix A. Change Log - - NB: to be removed by the RFC Editor before publication. - - draft-ietf-dnsext-dns-tcp-requirements-01 - Addition of response ordering section - Various minor editorial changes from WG reviewers - - draft-ietf-dnsext-dns-tcp-requirements-00 - Initial draft - - - - - - - -Bellis Expires April 29, 2010 [Page 7] - -Internet-Draft DNS Transport over TCP October 2009 - - -Author's Address - - Ray Bellis - Nominet UK - Edmund Halley Road - Oxford OX4 4DQ - United Kingdom - - Phone: +44 1865 332211 - Email: ray.bellis@nominet.org.uk - URI: http://www.nominet.org.uk/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Bellis Expires April 29, 2010 [Page 8] - diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt deleted file mode 100644 index 0953e28b471..00000000000 --- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt +++ /dev/null @@ -1,672 +0,0 @@ - - - -Network Working Group S. Weiler -Internet-Draft SPARTA, Inc. -Updates: 4033, 4034, 4035, 5155 D. Blacka -(if approved) VeriSign, Inc. -Intended status: Standards Track September 5, 2009 -Expires: March 9, 2010 - - - Clarifications and Implementation Notes for DNSSECbis - draft-ietf-dnsext-dnssec-bis-updates-09 - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on March 9, 2010. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - This document is a collection of technical clarifications to the - - - -Weiler & Blacka Expires March 9, 2010 [Page 1] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - DNSSECbis document set. It is meant to serve as a resource to - implementors as well as a repository of DNSSECbis errata. - - -Table of Contents - - 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3 - 1.1. Structure of this Document . . . . . . . . . . . . . . . . 3 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3 - 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 3 - 3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4 - 3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4 - 3.2. Validating Responses to an ANY Query . . . . . . . . . . . 4 - 3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5 - 3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5 - 4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5 - 4.1. Errors in Canonical Form Type Code List . . . . . . . . . 5 - 4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 5 - 4.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6 - 4.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7 - 4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7 - 4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7 - 4.7. Setting the AD bit on Replies . . . . . . . . . . . . . . 7 - 4.8. Setting the CD bit on Requests . . . . . . . . . . . . . . 8 - 4.9. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8 - 5. Minor Corrections and Clarifications . . . . . . . . . . . . . 8 - 5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 8 - 5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 9 - 5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 9 - 5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 9 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 - - - - - - - - - - - - -Weiler & Blacka Expires March 9, 2010 [Page 2] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - -1. Introduction and Terminology - - This document lists some additions, clarifications and corrections to - the core DNSSECbis specification, as originally described in - [RFC4033], [RFC4034], and [RFC4035]. - - It is intended to serve as a resource for implementors and as a - repository of items that need to be addressed when advancing the - DNSSECbis documents from Proposed Standard to Draft Standard. - -1.1. Structure of this Document - - The clarifications to DNSSECbis are sorted according to their - importance, starting with ones which could, if ignored, lead to - security problems and progressing down to clarifications that are - expected to have little operational impact. - -1.2. Terminology - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -2. Important Additions to DNSSSECbis - - This section updates the set of core DNSSEC protocol documents - originally specified in Section 10 of [RFC4033]. - -2.1. NSEC3 Support - - [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM - records for hashed denial of existence. Validator implementations - are strongly encouraged to include support for NSEC3 because a number - of highly visible zones are expected to use it. Validators that do - not support validation of responses using NSEC3 will likely be - hampered in validating large portions of the DNS space. - - [RFC5155] should be considered part of the DNS Security Document - Family as described by [RFC4033], Section 10. - -2.2. SHA-256 Support - - [RFC4509] describes the use of SHA-256 as a digest algorithm for use - with Delegation Signer (DS) RRs. [I-D.ietf-dnsext-dnssec-rsasha256] - describes the use of the RSASHA256 algorithm for use in DNSKEY and - RRSIG RRs. Validator implementations are strongly encouraged to - include support for this algorithm for DS, DNSKEY, and RRSIG records. - - - -Weiler & Blacka Expires March 9, 2010 [Page 3] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be - considered part of the DNS Security Document Family as described by - [RFC4033], Section 10. - - -3. Security Concerns - - This section provides clarifications that, if overlooked, could lead - to security issues. - -3.1. Clarifications on Non-Existence Proofs - - [RFC4035] Section 5.4 under-specifies the algorithm for checking non- - existence proofs. In particular, the algorithm as presented would - incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove - the non-existence of RRs in the child zone. - - An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with: - - o the NS bit set, - o the SOA bit clear, and - o a signer field that is shorter than the owner name of the NSEC RR, - or the original owner name for the NSEC3 RR. - - Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non- - existence of any RRs below that zone cut, which include all RRs at - that (original) owner name other than DS RRs, and all RRs below that - owner name regardless of type. - - Similarly, the algorithm would also allow an NSEC RR at the same - owner name as a DNAME RR, or an NSEC3 RR at the same original owner - name as a DNAME, to prove the non-existence of names beneath that - DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used - to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's - (original) owner name. - -3.2. Validating Responses to an ANY Query - - [RFC4035] does not address how to validate responses when QTYPE=*. - As described in Section 6.2.2 of [RFC1034], a proper response to - QTYPE=* may include a subset of the RRsets at a given name. That is, - it is not necessary to include all RRsets at the QNAME in the - response. - - When validating a response to QTYPE=*, all received RRsets that match - QNAME and QCLASS MUST be validated. If any of those RRsets fail - validation, the answer is considered Bogus. If there are no RRsets - matching QNAME and QCLASS, that fact MUST be validated according to - - - -Weiler & Blacka Expires March 9, 2010 [Page 4] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - the rules in [RFC4035] Section 5.4 (as clarified in this document). - To be clear, a validator must not expect to receive all records at - the QNAME in response to QTYPE=*. - -3.3. Check for CNAME - - Section 5 of [RFC4035] says little about validating responses based - on (or that should be based on) CNAMEs. When validating a NOERROR/ - NODATA response, validators MUST check the CNAME bit in the matching - NSEC or NSEC3 RR's type bitmap in addition to the bit for the query - type. Without this check, an attacker could successfully transform a - positive CNAME response into a NOERROR/NODATA response. - -3.4. Insecure Delegation Proofs - - [RFC4035] Section 5.2 specifies that a validator, when proving a - delegation is not secure, needs to check for the absence of the DS - and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also - needs to check for the presence of the NS bit in the matching NSEC - (or NSEC3) RR (proving that there is, indeed, a delegation), or - alternately make sure that the delegation is covered by an NSEC3 RR - with the Opt-Out flag set. If this is not checked, spoofed unsigned - delegations might be used to claim that an existing signed record is - not signed. - - -4. Interoperability Concerns - -4.1. Errors in Canonical Form Type Code List - - When canonicalizing DNS names, DNS names in the RDATA section of NSEC - and RRSIG resource records are not downcased. - - [RFC4034] Section 6.2 item 3 has a list of resource record types for - which DNS names in the RDATA are downcased for purposes of DNSSEC - canonical form (for both ordering and signing). That list - erroneously contains NSEC and RRSIG. According to [RFC3755], DNS - names in the RDATA of NSEC and RRSIG should not be downcased. - - The same section also erroneously lists HINFO, and twice at that. - Since HINFO records contain no domain names, they are not subject to - downcasing. - -4.2. Unknown DS Message Digest Algorithms - - Section 5.2 of [RFC4035] includes rules for how to handle delegations - to zones that are signed with entirely unsupported public key - algorithms, as indicated by the key algorithms shown in those zone's - - - -Weiler & Blacka Expires March 9, 2010 [Page 5] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - DS RRsets. It does not explicitly address how to handle DS records - that use unsupported message digest algorithms. In brief, DS records - using unknown or unsupported message digest algorithms MUST be - treated the same way as DS records referring to DNSKEY RRs of unknown - or unsupported public key algorithms. - - The existing text says: - - If the validator does not support any of the algorithms listed in - an authenticated DS RRset, then the resolver has no supported - authentication path leading from the parent to the child. The - resolver should treat this case as it would the case of an - authenticated NSEC RRset proving that no DS RRset exists, as - described above. - - To paraphrase the above, when determining the security status of a - zone, a validator disregards any DS records listing unknown or - unsupported algorithms. If none are left, the zone is treated as if - it were unsigned. - - Modified to consider DS message digest algorithms, a validator also - disregards any DS records using unknown or unsupported message digest - algorithms. - -4.3. Private Algorithms - - As discussed above, section 5.2 of [RFC4035] requires that validators - make decisions about the security status of zones based on the public - key algorithms shown in the DS records for those zones. In the case - of private algorithms, as described in [RFC4034] Appendix A.1.1, the - eight-bit algorithm field in the DS RR is not conclusive about what - algorithm(s) is actually in use. - - If no private algorithms appear in the DS set or if any supported - algorithm appears in the DS set, no special processing will be - needed. In the remaining cases, the security status of the zone - depends on whether or not the resolver supports any of the private - algorithms in use (provided that these DS records use supported hash - functions, as discussed in Section 4.2). In these cases, the - resolver MUST retrieve the corresponding DNSKEY for each private - algorithm DS record and examine the public key field to determine the - algorithm in use. The security-aware resolver MUST ensure that the - hash of the DNSKEY RR's owner name and RDATA matches the digest in - the DS RR. If they do not match, and no other DS establishes that - the zone is secure, the referral should be considered Bogus data, as - discussed in [RFC4035]. - - This clarification facilitates the broader use of private algorithms, - - - -Weiler & Blacka Expires March 9, 2010 [Page 6] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - as suggested by [RFC4955]. - -4.4. Caution About Local Policy and Multiple RRSIGs - - When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3 - suggests that "the local resolver security policy determines whether - the resolver also has to test these RRSIG RRs and how to resolve - conflicts if these RRSIG RRs lead to differing results." In most - cases, a resolver would be well advised to accept any valid RRSIG as - sufficient. If the first RRSIG tested fails validation, a resolver - would be well advised to try others, giving a successful validation - result if any can be validated and giving a failure only if all - RRSIGs fail validation. - - If a resolver adopts a more restrictive policy, there's a danger that - properly-signed data might unnecessarily fail validation, perhaps - because of cache timing issues. Furthermore, certain zone management - techniques, like the Double Signature Zone-signing Key Rollover - method described in section 4.2.1.2 of [RFC4641] might not work - reliably. - -4.5. Key Tag Calculation - - [RFC4034] Appendix B.1 incorrectly defines the Key Tag field - calculation for algorithm 1. It correctly says that the Key Tag is - the most significant 16 of the least significant 24 bits of the - public key modulus. However, [RFC4034] then goes on to incorrectly - say that this is 4th to last and 3rd to last octets of the public key - modulus. It is, in fact, the 3rd to last and 2nd to last octets. - -4.6. Setting the DO Bit on Replies - - [RFC4035] does not provide any instructions to servers as to how to - set the DO bit. Some authoritative server implementations have - chosen to copy the DO bit settings from the incoming query to the - outgoing response. Others have chosen to never set the DO bit in - responses. Either behavior is permitted. To be clear, in replies to - queries with the DO-bit set servers may or may not set the DO bit. - -4.7. Setting the AD bit on Replies - - Section 3.2.3 of [RFC4035] describes under which conditions a - validating resolver should set or clear the AD bit in a response. In - order to protect legacy stub resolvers and middleboxes, validating - resolvers SHOULD only set the AD bit when a response both meets the - conditions listed in RFC 4035, section 3.2.3, and the request - contained either a set DO bit or a set AD bit. - - - - -Weiler & Blacka Expires March 9, 2010 [Page 7] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - Note that the use of the AD bit in the query was previously - undefined. This document defines it as a signal indicating that the - requester understands and is interested in the value of the AD bit in - the response. This allows a requestor to indicate that it - understands the AD bit without also requesting DNSSEC data via the DO - bit. - -4.8. Setting the CD bit on Requests - - When processing a request with the CD bit set, the resolver MUST set - the CD bit on its upstream queries. - -4.9. Nested Trust Anchors - - A DNSSEC validator may be configured such that, for a given response, - more than one trust anchor could be used to validate the chain of - trust to the response zone. For example, imagine a validator - configured with trust anchors for "example." and "zone.example." - When the validator is asked to validate a response to - "www.sub.zone.example.", either trust anchor could apply. - - When presented with this situation, DNSSEC validators SHOULD try all - applicable trust anchors until one succeeds. - - There are some scenarios where different behaviors, such as choosing - the trust anchor closest to the QNAME of the response, may be - desired. A DNSSEC validator MAY enable such behaviors as - configurable overrides. - - -5. Minor Corrections and Clarifications - -5.1. Finding Zone Cuts - - Appendix C.8 of [RFC4035] discusses sending DS queries to the servers - for a parent zone. To do that, a resolver may first need to apply - special rules to discover what those servers are. - - As explained in Section 3.1.4.1 of [RFC4035], 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. Section 4.2 of - [RFC4035] specifies a mechanism for doing that. - - - - - - - -Weiler & Blacka Expires March 9, 2010 [Page 8] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - -5.2. Clarifications on DNSKEY Usage - - Questions of the form "can I use a different DNSKEY for signing this - RRset" have occasionally arisen. - - The short answer is "yes, absolutely". You can even use a different - DNSKEY for each RRset in a zone, subject only to practical limits on - the size of the DNSKEY RRset. However, be aware that there is no way - to tell resolvers what a particularly DNSKEY is supposed to be used - for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to - authenticate any RRset in the zone. For example, if a weaker or less - trusted DNSKEY is being used to authenticate NSEC RRsets or all - dynamically updated records, that same DNSKEY can also be used to - sign any other RRsets from the zone. - - Furthermore, note that the SEP bit setting has no effect on how a - DNSKEY may be used -- the validation process is specifically - prohibited from using that bit by [RFC4034] section 2.1.2. It is - possible to use a DNSKEY without the SEP bit set as the sole secure - entry point to the zone, yet use a DNSKEY with the SEP bit set to - sign all RRsets in the zone (other than the DNSKEY RRset). It's also - possible to use a single DNSKEY, with or without the SEP bit set, to - sign the entire zone, including the DNSKEY RRset itself. - -5.3. Errors in Examples - - The text in [RFC4035] Section C.1 refers to the examples in B.1 as - "x.w.example.com" while B.1 uses "x.w.example". This is painfully - obvious in the second paragraph where it states that the RRSIG labels - field value of 3 indicates that the answer was not the result of - wildcard expansion. This is true for "x.w.example" but not for - "x.w.example.com", which of course has a label count of 4 - (antithetically, a label count of 3 would imply the answer was the - result of a wildcard expansion). - - The first paragraph of [RFC4035] Section C.6 also has a minor error: - the reference to "a.z.w.w.example" should instead be "a.z.w.example", - as in the previous line. - -5.4. Errors in RFC 5155 - - A NSEC3 record that matches an Empty Non-Terminal effectively has no - type associated with it. This NSEC3 record has an empty type bit - map. Section 3.2.1 of [RFC5155] contains the statement: - - Blocks with no types present MUST NOT be included. - - However, the same section contains a regular expression: - - - -Weiler & Blacka Expires March 9, 2010 [Page 9] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+ - - The plus sign in the regular expression indicates that there is one - or more of the preceding element. This means that there must be at - least one window block. If this window block has no types, it - contradicts with the first statement. Therefore, the correct text in - RFC 5155 3.2.1 should be: - - Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )* - - -6. IANA Considerations - - This document specifies no IANA Actions. - - -7. Security Considerations - - This document adds two cryptographic features to the core DNSSEC - protocol. Additionally, it addresses some ambiguities and omissions - in the core DNSSEC documents that, if not recognized and addressed in - implementations, could lead to security failures. In particular, the - validation algorithm clarifications in Section 3 are critical for - preserving the security properties DNSSEC offers. Furthermore, - failure to address some of the interoperability concerns in Section 4 - could limit the ability to later change or expand DNSSEC, including - adding new algorithms. - - -8. References - -8.1. Normative References - - [I-D.ietf-dnsext-dnssec-rsasha256] - Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY - and RRSIG Resource Records for DNSSEC", - draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress), - June 2009. - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - RFC 1034, STD 13, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - - -Weiler & Blacka Expires March 9, 2010 [Page 10] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - -8.2. Informative References - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", - RFC 4641, September 2006. - - [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955, - July 2007. - - -Appendix A. Acknowledgments - - The editors would like the thank Rob Austein for his previous work as - an editor of this document. - - The editors are extremely grateful to those who, in addition to - finding errors and omissions in the DNSSECbis document set, have - provided text suitable for inclusion in this document. - - The lack of specificity about handling private algorithms, as - described in Section 4.3, and the lack of specificity in handling ANY - queries, as described in Section 3.2, were discovered by David - Blacka. - - The error in algorithm 1 key tag calculation, as described in - Section 4.5, was found by Abhijit Hayatnagarkar. Donald Eastlake - contributed text for Section 4.5. - - The bug relating to delegation NSEC RR's in Section 3.1 was found by - Roy Badami. Roy Arends found the related problem with DNAME. - - - - -Weiler & Blacka Expires March 9, 2010 [Page 11] - -Internet-Draft DNSSECbis Implementation Notes September 2009 - - - The errors in the [RFC4035] examples were found by Roy Arends, who - also contributed text for Section 5.3 of this document. - - The editors would like to thank Ed Lewis, Danny Mayer, Olafur - Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive - comments on the text of this document. - - -Authors' Addresses - - Samuel Weiler - SPARTA, Inc. - 7110 Samuel Morse Drive - Columbia, Maryland 21046 - US - - Email: weiler@tislabs.com - - - David Blacka - VeriSign, Inc. - 21345 Ridgetop Circle - Dulles, VA 20166 - US - - Email: davidb@verisign.com - - - - - - - - - - - - - - - - - - - - - - - - - -Weiler & Blacka Expires March 9, 2010 [Page 12] - diff --git a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt b/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt deleted file mode 100644 index 3b9a35aeaf7..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2672bis-dname-18.txt +++ /dev/null @@ -1,953 +0,0 @@ - - - -DNS Extensions Working Group S. Rose -Internet-Draft NIST -Obsoletes: 2672 (if approved) W. Wijngaards -Updates: 3363,4294 NLnet Labs -(if approved) November 12, 2009 -Intended status: Standards Track -Expires: May 16, 2010 - - - Update to DNAME Redirection in the DNS - draft-ietf-dnsext-rfc2672bis-dname-18 - -Abstract - - The DNAME record provides redirection for a sub-tree of the domain - name tree in the DNS system. That is, all names that end with a - particular suffix are redirected to another part of the DNS. This is - a revision of the original specification in RFC 2672, also aligning - RFC 3363 and RFC 4294 with this revision. - -Requirements Language - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. - -Status of This Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on May 16, 2010. - - - -Rose & Wijngaards Expires May 16, 2010 [Page 1] - -Internet-Draft DNAME Redirection November 2009 - - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - - This document may contain material from IETF Documents or IETF - Contributions published or made publicly available before November - 10, 2008. The person(s) controlling the copyright in some of this - material may not have granted the IETF Trust the right to allow - modifications of such material outside the IETF Standards Process. - Without obtaining an adequate license from the person(s) controlling - the copyright in such materials, this document may not be modified - outside the IETF Standards Process, and derivative works of it may - not be created outside the IETF Standards Process, except to format - it for publication as an RFC or to translate it into languages other - than English. - - - - - - - - - - - - - - - - - - - - - - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 2] - -Internet-Draft DNAME Redirection November 2009 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - - 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4 - 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 - 2.3. DNAME Owner Name not Redirected Itself . . . . . . . . . . 6 - 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 - 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 - - 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8 - 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 - 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10 - - 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11 - - 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 12 - 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 12 - 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12 - 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13 - 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13 - 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 13 - 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 13 - 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 13 - 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 13 - 5.3.4.2. Valid Name Error Response Involving DNAME in - Bitmap . . . . . . . . . . . . . . . . . . . . . . 14 - 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 14 - - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 - - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 - - - - - - - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 3] - -Internet-Draft DNAME Redirection November 2009 - - -1. Introduction - - DNAME is a DNS Resource Record type originally defined in RFC 2672 - [RFC2672]. DNAME provides redirection from a part of the DNS name - tree to another part of the DNS name tree. - - The DNAME RR and the CNAME RR [RFC1034] cause a lookup to - (potentially) return data corresponding to a domain name different - from the queried domain name. The difference between the two - resource records is that the CNAME RR directs the lookup of data at - its owner to another single name, a DNAME RR directs lookups for data - at descendents of its owner's name to corresponding names under a - different (single) node of the tree. - - Take for example, looking through a zone (see RFC 1034 [RFC1034], - section 4.3.2, step 3) for the domain name "foo.example.com" and a - DNAME resource record is found at "example.com" indicating that all - queries under "example.com" be directed to "example.net". The lookup - process will return to step 1 with the new query name of - "foo.example.net". Had the query name been "www.foo.example.com" the - new query name would be "www.foo.example.net". - - This document is a revision of the original specification of DNAME in - RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of - maintaining address-to-name mappings in a context of network - renumbering. With a careful set-up, a renumbering event in the - network causes no change to the authoritative server that has the - address-to-name mappings. Examples in practice are classless reverse - address space delegations. - - Another usage of DNAME lies in aliasing of name spaces. For example, - a zone administrator may want sub-trees of the DNS to contain the - same information. Examples include punycode alternates for domain - spaces. - - This revision to DNAME does not change the wire format or the - handling of DNAME Resource Records. Discussion is added on problems - that may be encountered when using DNAME. - -2. The DNAME Resource Record - -2.1. Format - - The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is - not class-sensitive. - - - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 4] - -Internet-Draft DNAME Redirection November 2009 - - - Its RDATA is comprised of a single field, , which contains a - fully qualified domain name that must be sent in uncompressed form - [RFC1035], [RFC3597]. The field MUST be present. The - presentation format of is that of a domain name [RFC1035]. - - DNAME - - The effect of the DNAME RR is the substitution of the record's - for its owner name, as a suffix of a domain name. This - substitution has to be applied for every DNAME RR found in the - resolution process, which allows fairly lengthy valid chains of DNAME - RRs. - - Details of the substitution process, methods to avoid conflicting - resource records, and rules for specific corner cases are given in - the following subsections. - -2.2. The DNAME Substitution - - When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third - step, "start matching down, label by label, in the zone" and a node - is found to own a DNAME resource record a DNAME substitution occurs. - The name being sought may be the original query name or a name that - is the result of a CNAME resource record being followed or a - previously encountered DNAME. As in the case when finding a CNAME - resource record or NS resource record set, the processing of a DNAME - will happen prior to finding the desired domain name. - - A DNAME substitution is performed by replacing the suffix labels of - the name being sought matching the owner name of the DNAME resource - record with the string of labels in the RDATA field. The matching - labels end with the root label in all cases. Only whole labels are - replaced. See the table of examples for common cases and corner - cases. - - - - - - - - - - - - - - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 5] - -Internet-Draft DNAME Redirection November 2009 - - - In the table below, the QNAME refers to the query name. The owner is - the DNAME owner domain name, and the target refers to the target of - the DNAME record. The result is the resulting name after performing - the DNAME substitution on the query name. "no match" means that the - query did not match the DNAME and thus no substitution is performed - and a possible error message is returned (if no other result is - possible). Thus every line contains one example substitution. In - the examples below, 'cyc' and 'shortloop' contain loops. - - QNAME owner DNAME target result - ---------------- -------------- -------------- ----------------- - com. example.com. example.net. - example.com. example.com. example.net. - a.example.com. example.com. example.net. a.example.net. - a.b.example.com. example.com. example.net. a.b.example.net. - ab.example.com. b.example.com. example.net. - foo.example.com. example.com. example.net. foo.example.net. - a.x.example.com. x.example.com. example.net. a.example.net. - a.example.com. example.com. y.example.net. a.y.example.net. - cyc.example.com. example.com. example.com. cyc.example.com. - cyc.example.com. example.com. c.example.com. cyc.c.example.com. - shortloop.x.x. x. . shortloop.x. - shortloop.x. x. . shortloop. - - Table 1. DNAME Substitution Examples. - - It is possible for DNAMEs to form loops, just as CNAMEs can form - loops. DNAMEs and CNAMEs can chain together to form loops. A single - corner case DNAME can form a loop. Resolvers and servers should be - cautious in devoting resources to a query, but be aware that fairly - long chains of DNAMEs may be valid. Zone content administrators - should take care to insure that there are no loops that could occur - when using DNAME or DNAME/CNAME redirection. - - The domain name can get too long during substitution. For example, - suppose the target name of the DNAME RR is 250 octets in length - (multiple labels), if an incoming QNAME that has a first label over 5 - octets in length, the result would be a name over 255 octets. If - this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The - DNAME record and its signature (if the zone is signed) are included - in the answer as proof for the YXDOMAIN (value 6) RCODE. - -2.3. DNAME Owner Name not Redirected Itself - - Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its - owner name; the owner name of a DNAME is not redirected itself. The - domain name that owns a DNAME record is allowed to have other - resource record types at that domain name, except DNAMEs, CNAMEs or - - - -Rose & Wijngaards Expires May 16, 2010 [Page 6] - -Internet-Draft DNAME Redirection November 2009 - - - other types that have restrictions on what they can co-exist with. - DNAME RRs MUST NOT appear at the same owner name as an NS RR unless - the owner name is the zone apex. - - If a DNAME record is present at the zone apex, there is still a need - to have the customary SOA and NS resource records there as well. - Such a DNAME cannot be used to mirror a zone completely, as it does - not mirror the zone apex. - - These rules also allow DNAME records to be queried through RFC 1034 - [RFC1034] compliant, DNAME-unaware caches. - -2.4. Names Next to and Below a DNAME Record - - Resource records MUST NOT exist at any sub-domain of the owner of a - DNAME RR. To get the contents for names subordinate to that owner - name, the DNAME redirection must be invoked and the resulting target - queried. A server MAY refuse to load a zone that has data at a sub- - domain of a domain name owning a DNAME RR. If the server does load - the zone, those names below the DNAME RR will be occluded as - described in RFC 2136 [RFC2136], section 7.18. Also a server SHOULD - refuse to load a zone subordinate to the owner of a DNAME record in - the ancestor zone. See Section 5.2 for further discussion related to - dynamic update. - - DNAME is a singleton type, meaning only one DNAME is allowed per - name. The owner name of a DNAME can only have one DNAME RR, and no - CNAME RRs can exist at that name. These rules make sure that for a - single domain name only one redirection exists, and thus no confusion - which one to follow. A server SHOULD refuse to load a zone that - violates these rules. - -2.5. Compression of the DNAME record. - - The DNAME owner name can be compressed like any other owner name. - The DNAME RDATA target name MUST NOT be sent out in compressed form, - so that a DNAME RR can be treated as an unknown type [RFC3597]. - - Although the previous DNAME specification [RFC2672] (that is - obsoleted by this specification) talked about signaling to allow - compression of the target name, such signaling has never been - specified and this document also does not specify this signaling - behavior. - - RFC 2672 (obsoleted by this document) stated that the EDNS version - had a meaning for understanding of DNAME and DNAME target name - compression. This document revises RFC 2672, in that there is no - EDNS version signaling for DNAME. - - - -Rose & Wijngaards Expires May 16, 2010 [Page 7] - -Internet-Draft DNAME Redirection November 2009 - - -3. Processing - - The DNAME RR causes type NS additional section processing. This - refers to action at step 6 of the server algorithm outlined in - section 3.2. - -3.1. CNAME synthesis - - When preparing a response, a server performing a DNAME substitution - will in all cases include the relevant DNAME RR in the answer - section. A CNAME RR with TTL equal to the corresponding DNAME RR is - synthesized and included in the answer section. The owner name of - the CNAME is the QNAME of the query. The DNSSEC specification - [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does - not have to be signed. The DNAME has an RRSIG and a validating - resolver can check the CNAME against the DNAME record and validate - the signature over the DNAME RR. - - Resolvers MUST be able to handle a synthesized CNAME TTL of zero or - equal to the TTL of the corresponding DNAME record. A TTL of zero - means that the CNAME can be discarded immediately after processing - the answer. - - Servers MUST be able to answer a query for a synthesized CNAME. Like - other query types this invokes the DNAME, and synthesizes the CNAME - into the answer. - -3.2. Server algorithm - - Below is the server algorithm, which appeared in RFC 2672 Section - 4.1. - - 1. Set or clear the value of recursion available in the response - depending on whether the name server is willing to provide - recursive service. If recursive service is available and - requested via the RD bit in the query, go to step 5, otherwise - step 2. - - - 2. Search the available zones for the zone which is the nearest - ancestor to QNAME. If such a zone is found, go to step 3, - otherwise step 4. - - - 3. Start matching down, label by label, in the zone. The matching - process can terminate several ways: - - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 8] - -Internet-Draft DNAME Redirection November 2009 - - - A. If the whole of QNAME is matched, we have found the node. - - If the data at the node is a CNAME, and QTYPE does not match - CNAME, copy the CNAME RR into the answer section of the - response, change QNAME to the canonical name in the CNAME RR, - and go back to step 1. - - Otherwise, copy all RRs which match QTYPE into the answer - section and go to step 6. - - - B. If a match would take us out of the authoritative data, we - have a referral. This happens when we encounter a node with - NS RRs marking cuts along the bottom of a zone. - - Copy the NS RRs for the sub-zone into the authority section - of the reply. Put whatever addresses are available into the - additional section, using glue RRs if the addresses are not - available from authoritative data or the cache. Go to step - 4. - - - C. If at some label, a match is impossible (i.e., the - corresponding label does not exist), look to see whether the - last label matched has a DNAME record. - - If a DNAME record exists at that point, copy that record into - the answer section. If substitution of its for its - in QNAME would overflow the legal size for a , set RCODE to YXDOMAIN [RFC2136] and exit; otherwise - perform the substitution and continue. The server MUST - synthesize a CNAME record as described above and include it - in the answer section. Go back to step 1. - - If there was no DNAME record, look to see if the "*" label - exists. - - If the "*" label does not exist, check whether the name we - are looking for is the original QNAME in the query or a name - we have followed due to a CNAME or DNAME. If the name is - original, set an authoritative name error in the response and - exit. Otherwise just exit. - - If the "*" label does exist, match RRs at that node against - QTYPE. If any match, copy them into the answer section, but - set the owner of the RR to be QNAME, and not the node with - the "*" label. If the data at the node with the "*" label is - a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR - - - -Rose & Wijngaards Expires May 16, 2010 [Page 9] - -Internet-Draft DNAME Redirection November 2009 - - - into the answer section of the response changing the owner - name to the QNAME, change QNAME to the canonical name in the - CNAME RR, and go back to step 1. Otherwise, Go to step 6. - - - 4. Start matching down in the cache. If QNAME is found in the - cache, copy all RRs attached to it that match QTYPE into the - answer section. If QNAME is not found in the cache but a DNAME - record is present at an ancestor of QNAME, copy that DNAME record - into the answer section. If there was no delegation from - authoritative data, look for the best one from the cache, and put - it in the authority section. Go to step 6. - - - 5. Use the local resolver or a copy of its algorithm to answer the - query. Store the results, including any intermediate CNAMEs and - DNAMEs, in the answer section of the response. - - - 6. Using local data only, attempt to add other RRs which may be - useful to the additional section of the query. Exit. - - Note that there will be at most one ancestor with a DNAME as - described in step 4 unless some zone's data is in violation of the - no-descendants limitation in section 3. An implementation might take - advantage of this limitation by stopping the search of step 3c or - step 4 when a DNAME record is encountered. - -3.3. Wildcards - - The use of DNAME in conjunction with wildcards is discouraged - [RFC4592]. Thus records of the form "*.example.com DNAME - example.net" SHOULD NOT be used. - - The interaction between the expansion of the wildcard and the - redirection of the DNAME is non-deterministic. Because the - processing is non-deterministic, DNSSEC validating resolvers may not - be able to validate a wildcarded DNAME. - - A server MAY give a warning that the behavior is unspecified if such - a wildcarded DNAME is loaded. The server MAY refuse it, refuse to - load the zone or refuse dynamic updates. - -3.4. Acceptance and Intermediate Storage - - Recursive caching name servers can encounter data at names below the - owner name of a DNAME RR, due to a change at the authoritative server - where data from before and after the change resides in the cache. - - - -Rose & Wijngaards Expires May 16, 2010 [Page 10] - -Internet-Draft DNAME Redirection November 2009 - - - This conflict situation is a transitional phase that ends when the - old data times out. The caching name server can opt to store both - old and new data and treat each as if the other did not exist, or - drop the old data, or drop the longer domain name. In any approach, - consistency returns after the older data TTL times out. - - Recursive caching name servers MUST perform CNAME synthesis on behalf - of clients. - - If a recursive caching name server encounters a DNAME RR which - contradicts information already in the cache (excluding CNAME - records), it SHOULD NOT cache the DNAME RR, but it MAY cache the - CNAME record received along with it, subject to the rules for CNAME. - -4. DNAME Discussions in Other Documents - - In [RFC2181], in Section 10.3., the discussion on MX and NS records - touches on redirection by CNAMEs, but this also holds for DNAMEs. - - Excerpt from 10.3. MX and NS records (in RFC 2181). - - The domain name used as the value of a NS resource record, - or part of the value of a MX resource record must not be - an alias. Not only is the specification clear on this - point, but using an alias in either of these positions - neither works as well as might be hoped, nor well fulfills - the ambition that may have led to this approach. This - domain name must have as its value one or more address - records. Currently those will be A records, however in - the future other record types giving addressing - information may be acceptable. It can also have other - RRs, but never a CNAME RR. - - The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME. - The opening premise of this section is demonstrably wrong, and so the - conclusion based on that premise is wrong. In particular, [RFC3363] - deprecates the use of DNAME in the IPv6 reverse tree, which is then - carried forward as a recommendation in [RFC4294]. Based on the - experience gained in the meantime, [RFC3363] should be revised, - dropping all constraints on having DNAME RRs in these zones. This - would greatly improve the manageability of the IPv6 reverse tree. - These changes are made explicit below. - - - - - - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 11] - -Internet-Draft DNAME Redirection November 2009 - - - In [RFC3363], the paragraph - - "The issues for DNAME in the reverse mapping tree appears to be - closely tied to the need to use fragmented A6 in the main tree: if - one is necessary, so is the other, and if one isn't necessary, the - other isn't either. Therefore, in moving RFC 2874 to experimental, - the intent of this document is that use of DNAME RRs in the reverse - tree be deprecated." - - is to be replaced with the word "DELETED". - - In [RFC4294], the reference to DNAME was left in as an editorial - oversight. The paragraph - - "Those nodes are NOT RECOMMENDED to support the experimental A6 and - DNAME Resource Records [RFC3363]." - - is to be replaced by - - "Those nodes are NOT RECOMMENDED to support the experimental - A6 Resource Record [RFC3363]." - -5. Other Issues with DNAME - - There are several issues to be aware of about the use of DNAME. - -5.1. Canonical hostnames cannot be below DNAME owners - - The names listed as target names of MX, NS, PTR and SRV [RFC2782] - records must be canonical hostnames. This means no CNAME or DNAME - redirection may be present during DNS lookup of the address records - for the host. This is discussed in RFC 2181 [RFC2181], section 10.3, - and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782] - page 4. - - The upshot of this is that although the lookup of a PTR record can - involve DNAMEs, the name listed in the PTR record can not fall under - a DNAME. The same holds for NS, SRV and MX records. For example, - when punycode alternates for a zone use DNAME then the NS, MX, SRV - and PTR records that point to that zone must use names without - punycode in their RDATA. What must be done then is to have the - domain names with DNAME substitution already applied to it as the MX, - NS, PTR, SRV data. These are valid canonical hostnames. - -5.2. Dynamic Update and DNAME - - DNAME records can be added, changed and removed in a zone using - dynamic update transactions. Adding a DNAME RR to a zone occludes - - - -Rose & Wijngaards Expires May 16, 2010 [Page 12] - -Internet-Draft DNAME Redirection November 2009 - - - any domain names that may exist under the added DNAME. - - A server MUST reject a dynamic update message that attempts to add a - DNAME RR at a name that already has a CNAME RR or another DNAME RR - associated with that name. - -5.3. DNSSEC and DNAME - - The following subsections specify the behavior of implementations - that understand both DNSSEC and DNAME (synthesis). - -5.3.1. Signed DNAME, Unsigned Synthesized CNAME - - In any response, a signed DNAME RR indicates a non-terminal - redirection of the query. There might or might not be a server - synthesized CNAME in the answer section; if there is, the CNAME will - never be signed. For a DNSSEC validator, verification of the DNAME - RR and then checking that the CNAME was properly synthesized is - sufficient proof. - -5.3.2. DNAME Bit in NSEC Type Map - - In any negative response, the NSEC or NSEC3 [RFC5155] record type bit - map SHOULD be checked to see that there was no DNAME that could have - been applied. If the DNAME bit in the type bit map is set and the - query name is a subdomain of the closest encloser that is asserted, - then DNAME substitution should have been done, but the substitution - has not been done as specified. - -5.3.3. DNAME Chains as Strong as the Weakest Link - - A response can contain a chain of DNAME and CNAME redirections. That - chain can end in a positive answer or a negative (no name error or no - data error) reply. Each step in that chain results in resource - records added to the answer or authority section of the response. - Only if all steps are secure can the AD bit be set for the response. - If one of the steps is bogus, the result is bogus. - -5.3.4. Validators Must Understand DNAME - - Below are examples of why DNSSEC validators MUST understand DNAME. - In the examples below, SOA records, wildcard denial NSECs and other - material not under discussion has been omitted. - -5.3.4.1. DNAME in Bitmap Causes Invalid Name Error - - - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 13] - -Internet-Draft DNAME Redirection November 2009 - - - ;; Header: QR AA DO RCODE=3(NXDOMAIN) - ;; Question - foo.bar.example.com. IN A - ;; Authority - bar.example.com. NSEC dub.example.com. A DNAME - bar.example.com. RRSIG NSEC [valid signature] - - If this is the received response, then only by understanding that the - DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to - have been redirected by the DNAME, the validator can see that it is a - BOGUS reply from an attacker that collated existing records from the - DNS to create a confusing reply. - - If the DNAME bit had not been set in the NSEC record above then the - answer would have validated as a correct name error response. - -5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap - - ;; Header: QR AA DO RCODE=3(NXDOMAIN) - ;; Question - cee.example.com. IN A - ;; Authority - bar.example.com. NSEC dub.example.com. A DNAME - bar.example.com. RRSIG NSEC [valid signature] - - This response has the same NSEC records as the example above, but - with this query name (cee.example.com), the answer is validated, - because 'cee' does not get redirected by the DNAME at 'bar'. - -5.3.4.3. Response With Synthesized CNAME - - ;; Header: QR AA DO RCODE=0(NOERROR) - ;; Question - foo.bar.example.com. IN A - ;; Answer - bar.example.com. DNAME bar.example.net. - bar.example.com. RRSIG DNAME [valid signature] - foo.bar.example.com. CNAME foo.bar.example.net. - - The response shown above has the synthesized CNAME included. - However, the CNAME has no signature, since the server does not sign - online. So this response cannot be trusted. It could be altered by - an attacker to be foo.bar.example.com CNAME bla.bla.example. The - DNAME record does have its signature included, since it does not - change. The validator must verify the DNAME signature and then - recursively resolve further to query for the foo.bar.example.net A - record. - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 14] - -Internet-Draft DNAME Redirection November 2009 - - -6. IANA Considerations - - The DNAME Resource Record type code 39 (decimal) originally has been - registered by [RFC2672]. IANA should update the DNS resource record - registry to point to this document for RR type 39. - -7. Security Considerations - - DNAME redirects queries elsewhere, which may impact security based on - policy and the security status of the zone with the DNAME and the - redirection zone's security status. For validating resolvers, the - lowest security status of the links in the chain of CNAME and DNAME - redirections is applied to the result. - - If a validating resolver accepts wildcarded DNAMEs, this creates - security issues. Since the processing of a wildcarded DNAME is non- - deterministic and the CNAME that was substituted by the server has no - signature, the resolver may choose a different result than what the - server meant, and consequently end up at the wrong destination. Use - of wildcarded DNAMEs is discouraged in any case [RFC4592]. - - A validating resolver MUST understand DNAME, according to [RFC4034]. - The examples in Section 5.3.4 illustrate this need. - -8. Acknowledgments - - The authors of this draft would like to acknowledge Matt Larson for - beginning this effort to address the issues related to the DNAME RR - type. The authors would also like to acknowledge Paul Vixie, Ed - Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred - Hoenes and Kevin Darcy for their review and comments on this - document. - -9. References - -9.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - - - -Rose & Wijngaards Expires May 16, 2010 [Page 15] - -Internet-Draft DNAME Redirection November 2009 - - - RFC 2136, April 1997. - - [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. - - [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", RFC 2782, - February 2000. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name - System", RFC 4592, July 2006. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - -9.2. Informative References - - [RFC1912] Barr, D., "Common DNS Operational and Configuration - Errors", RFC 1912, February 1996. - - [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", - RFC 2672, August 1999. - - [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. - Hain, "Representing Internet Protocol version 6 (IPv6) - Addresses in the Domain Name System (DNS)", RFC 3363, - August 2002. - - [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, - April 2006. - - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 16] - -Internet-Draft DNAME Redirection November 2009 - - -Authors' Addresses - - Scott Rose - NIST - 100 Bureau Dr. - Gaithersburg, MD 20899 - USA - - Phone: +1-301-975-8439 - Fax: +1-301-975-6238 - EMail: scottr@nist.gov - - - Wouter Wijngaards - NLnet Labs - Science Park 140 - Amsterdam 1098 XG - The Netherlands - - Phone: +31-20-888-4551 - EMail: wouter@nlnetlabs.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Rose & Wijngaards Expires May 16, 2010 [Page 17] - - diff --git a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt deleted file mode 100644 index ee35cb91af8..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -INTERNET-DRAFT A. Gustafsson - Araneus Information Systems Oy - September 23, 2009 - -Intended status: Draft Standard -Obsoletes: RFC3597 - - Handling of Unknown DNS Resource Record (RR) Types - draft-ietf-dnsext-rfc3597-bis-00.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - 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 - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - Extending the Domain Name System (DNS) with new Resource Record (RR) - types should not requires changes to name server software. This - document specifies how new RR types are transparently handled by DNS - software. - - - - -Expires March 2010 Standards Track [Page 1] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - -1. Introduction - - The DNS [RFC1034] is designed to be extensible to support new - services through the introduction of new resource record (RR) types. - Nevertheless, DNS implementations have historically required software - changes to support new RR types, not only at the authoritative DNS - server providing the new information and the client making use of it, - but also at all slave servers for the zone containing it, and in some - cases also at caching name servers and forwarders used by the client. - Because the deployment of new DNS software is slow and expensive, - this has been a significant impediment to supporting new services in - the DNS. - - [RFC3597] defined DNS implementation behavior and procedures for - defining new RR types aimed at simplifying the deployment of new RR - types by allowing them to be treated transparently by existing - implementations. Thanks to the widespread adoption of that - specification, much of the DNS is now capable of handling new record - types without software changes. - - This document is a self-contained revised specification supplanting - and obsoleting [RFC3597]. - -2. Definitions - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - An "RR of unknown type" is an RR whose RDATA format is not known to - the DNS implementation at hand, and whose type is not an assigned - QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within - the range reserved in that section for assignment only to QTYPEs and - Meta-TYPEs. Such an RR cannot be converted to a type-specific text - format, compressed, or otherwise handled in a type-specific way. - - In the case of a type whose RDATA format is class specific, an RR is - considered to be of unknown type when the RDATA format for that - combination of type and class is not known. - -3. Transparency - - To enable new RR types to be deployed without server changes, name - servers and resolvers MUST handle RRs of unknown type transparently. - That is, they must treat the RDATA section of such RRs as - unstructured binary data, storing and transmitting it without change - [RFC1123]. - - - - -Expires March 2010 Standards Track [Page 2] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - To ensure the correct operation of equality comparison (section 6) - and of the DNSSEC canonical form (section 7) when an RR type is known - to some but not all of the servers involved, servers MUST also - exactly preserve the RDATA of RRs of known type, except for changes - due to compression or decompression where allowed by section 4 of - this document. In particular, the character case of domain names - that are not subject to compression MUST be preserved. - -4. Domain Name Compression - - RRs containing compression pointers in the RDATA part cannot be - treated transparently, as the compression pointers are only - meaningful within the context of a DNS message. Transparently - copying the RDATA into a new DNS message would cause the compression - pointers to point at the corresponding location in the new message, - which now contains unrelated data. This would cause the compressed - name to be corrupted. - - To avoid such corruption, servers MUST NOT compress domain names - embedded in the RDATA of types that are class-specific or not well- - known. This requirement was stated in [RFC1123] without defining the - term "well-known"; it is hereby specified that only the RR types - defined in [RFC1035] are to be considered "well-known". - - Receiving servers MUST decompress domain names in RRs of well-known - type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, - NXT, NAPTR, and SRV to ensure interoperability with implementations - predating [RFC3597]. - - Specifications for new RR types that contain domain names within - their RDATA MUST NOT allow the use of name compression for those - names, and SHOULD explicitly state that the embedded domain names - MUST NOT be compressed. - - As noted in [RFC1123], the owner name of an RR is always eligible for - compression. - -5. Text Representation - - In the "type" field of a master file line, an unknown RR type is - represented by the word "TYPE" immediately followed by the decimal RR - type number, with no intervening whitespace. In the "class" field, - an unknown class is similarly represented as the word "CLASS" - immediately followed by the decimal class number. - - This convention allows types and classes to be distinguished from - each other and from TTL values, allowing the "[] [] - " and "[] [] " forms of - - - -Expires March 2010 Standards Track [Page 3] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - [RFC1035] to both be unambiguously parsed. - - The RDATA section of an RR of unknown type is represented as a - sequence of white space separated words as follows: - - The special token \# (a backslash immediately followed by a hash - sign), which identifies the RDATA as having the generic encoding - defined herein rather than a traditional type-specific encoding. - - An unsigned decimal integer specifying the RDATA length in octets. - - Zero or more words of hexadecimal data encoding the actual RDATA - field, each containing an even number of hexadecimal digits. - - If the RDATA is of zero length, the text representation contains only - the \# token and the single zero representing the length. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires March 2010 Standards Track [Page 4] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - An implementation MAY also choose to represent some RRs of known type - using the above generic representations for the type, class and/or - RDATA, which carries the benefit of making the resulting master file - portable to servers where these types are unknown. Using the generic - representation for the RDATA of an RR of known type can also be - useful in the case of an RR type where the text format varies - depending on a version, protocol, or similar field (or several) - embedded in the RDATA when such a field has a value for which no text - format is known, e.g., a LOC RR [RFC1876] with a VERSION other than - 0. - - Even though an RR of known type represented in the \# format is - effectively treated as an unknown type for the purpose of parsing the - RDATA text representation, all further processing by the server MUST - treat it as a known type and take into account any applicable type- - specific rules regarding compression, canonicalization, etc. - - The following are examples of RRs represented in this manner, - illustrating various combinations of generic and type-specific - encodings for the different fields of the master file format: - - a.example. CLASS32 TYPE731 \# 6 abcd ( - ef 01 23 45 ) - b.example. HS TYPE62347 \# 0 - e.example. IN A \# 4 C0000201 - e.example. CLASS1 TYPE1 192.0.2.1 - -6. Equality Comparison - - Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs - to be compared for equality. Two RRs of the same unknown type are - considered equal when their RDATA is bitwise equal. To ensure that - the outcome of the comparison is identical whether the RR is known to - the server or not, specifications for new RR types MUST NOT specify - type-specific comparison rules. - - This implies that embedded domain names, being included in the - overall bitwise comparison, are compared in a case-sensitive manner. - - As a result, when a new RR type contains one or more embedded domain - names, it is possible to have multiple RRs owned by the same name - that differ only in the character case of the embedded domain - name(s). This is similar to the existing possibility of multiple TXT - records differing only in character case, and not expected to cause - any problems in practice. - - - - - - -Expires March 2010 Standards Track [Page 5] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - -7. DNSSEC Considerations - - The rules for the DNSSEC canonical form and ordering were updated to - support transparent treatment of unknown types in [RFC3597]. Those - updates have subsequently been integrated into the base DNSSEC - specification, such that the DNSSEC canonical form and ordering are - now specified in [RFC4034] or its successors rather than in this - document. - -8. Additional Section Processing - - Unknown RR types cause no additional section processing. Future RR - type specifications MAY specify type-specific additional section - processing rules, but any such processing MUST be optional as it can - only be performed by servers for which the RR type in case is known. - -9. IANA Considerations - - This document does not require any IANA actions. - -10. Security Considerations - - This specification is not believed to cause any new security - problems, nor to solve any existing ones. - -11. Normative References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities", STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specifications", STD 13, RFC 1035, November 1987. - - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -- - Application and Support", STD 3, RFC 1123, October 1989. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA - Considerations", BCP 42, RFC 5395, November 2008. - -12. Informative References - - [RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A - Means for Expressing Location Information in the Domain - Name System", RFC 1876, January 1996. - - - - -Expires March 2010 Standards Track [Page 6] - -draft-ietf-dnsext-rfc3597-bis-00.txt July 2009 - - - [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - -14. Author's Address - - Andreas Gustafsson - Araneus Information Systems Oy - PL 110 - 02321 Espoo - Finland - - Phone: +358 40 547 2099 - EMail: gson@araneus.fi - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires March 2010 Standards Track [Page 7] - diff --git a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt b/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt deleted file mode 100644 index 72d38aa267a..00000000000 --- a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt +++ /dev/null @@ -1,336 +0,0 @@ - - - -DNSext Working Group F. Dupont -Internet-Draft ISC -Updates: 2845,2930,4635 May 8, 2009 -(if approved) -Intended status: Standards Track -Expires: November 9, 2009 - - - Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records - draft-ietf-dnsext-tsig-md5-deprecated-03.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - from IETF Documents or IETF Contributions published or made publicly - available before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the IETF - Trust the right to allow modifications of such material outside the - IETF Standards Process. Without obtaining an adequate license from - the person(s) controlling the copyright in such materials, this - document may not be modified outside the IETF Standards Process, and - derivative works of it may not be created outside the IETF Standards - Process, except to format it for publication as an RFC or to - translate it into languages other than English. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 9, 2009. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - - -Dupont Expires November 9, 2009 [Page 1] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - The main purpose of this document is to deprecate the use of HMAC-MD5 - as an algorithm for the TSIG (secret key transaction authentication) - resource record in the DNS (domain name system), and the use of MD5 - in TKEY (secret key establishment for DNS). - - -1. Introduction - - The secret key transaction authentication for DNS (TSIG, [RFC2845]) - was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm. - When the MD5 [RFC1321] security came to be considered lower than - expected, [RFC4635] standardized new TSIG algorithms based on SHA - [RFC3174][RFC3874][RFC4634] digests. - - But [RFC4635] did not deprecate the HMAC-MD5 algorithm. This - document is targeted to complete the process, in detail: - 1. Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm - name registry managed by the IANA under the IETF Review Policy - [RFC5226] - 2. Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for - implementations - 3. Provide a keying material derivation for the secret key - establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman - exchange with SHA256 [RFC4634] in place of MD5 [RFC1321] - 4. Finally recommend the use of HMAC-SHA256. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -2. Implementation Requirements - - The table of section 3 of [RFC4635] is replaced by: - - - - - - - - - -Dupont Expires November 9, 2009 [Page 2] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - +-------------------+--------------------------+ - | Requirement Level | Algorithm Name | - +-------------------+--------------------------+ - | Optional | HMAC-MD5.SIG-ALG.REG.INT | - | Optional | gss-tsig | - | Mandatory | hmac-sha1 | - | Optional | hmac-sha224 | - | Mandatory | hmac-sha256 | - | Optional | hmac-sha384 | - | Optional | hmac-sha512 | - +-------------------+--------------------------+ - - Implementations that support TSIG MUST also implement HMAC-SHA1 and - HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level) - and MAY implement GSS-TSIG and the other algorithms listed above - (i.e., algorithms at a "not Mandatory" requirement level). - - -3. TKEY keying material derivation - - When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying - material is derived from the shared secret and TKEY resource record - data using MD5 [RFC1321] at the end of section 4.1 page 9. - - This is amended into: - - keying material = - XOR ( DH value, SHA256 ( query data | DH value ) | - SHA256 ( server data | DH value ) ) - - using the same conventions. - - -4. IANA Consideration - - This document extends the "TSIG Algorithm Names - per [] and - [RFC2845]" located at - http://www.iana.org/assignments/tsig-algorithm-names by adding a new - column to the registry "Compliance Requirement". - - The registry should contain the following: - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 3] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - +--------------------------+------------------------+-------------+ - | Algorithm Name | Compliance Requirement | Reference | - +--------------------------+------------------------+-------------+ - | gss-tsig | Optional | [RFC3645] | - | HMAC-MD5.SIG-ALG.REG.INT | Optional | [][RFC2845] | - | hmac-sha1 | Mandatory | [RFC4635] | - | hmac-sha224 | Optional | [RFC4635] | - | hmac-sha256 | Mandatory | [RFC4635] | - | hmac-sha384 | Optional | [RFC4635] | - | hmac-sha512 | Optional | [RFC4635] | - +--------------------------+------------------------+-------------+ - - where [] is this document. - - -5. Availability Considerations - - MD5 is no longer universally available and its use may lead to - increasing operation issues. SHA1 is likely to suffer from the same - kind of problem. In summary MD5 has reached end-of-life and SHA1 - will likely follow in the near term. - - According to [RFC4635], implementations which support TSIG are - REQUIRED to implement HMAC-SHA256. - - -6. Security Considerations - - This document does not assume anything about the cryptographic - security of different hash algorithms. Its purpose is a better - availability of some security mechanisms in a predictable time frame. - - Requirement levels are adjusted for TSIG and related specifications - (i.e., TKEY): - The support of HMAC-MD5 is changed from mandatory to optional. - The use of MD5 and HMAC-MD5 is NOT RECOMMENDED. - The use of HMAC-SHA256 is RECOMMENDED. - - -7. Acknowledgments - - Olafur Gudmundsson kindly helped in the procedure to deprecate the - MD5 use in TSIG, i.e., the procedure which led to this memo. Alfred - Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some - improvements. - - -8. References - - - -Dupont Expires November 9, 2009 [Page 4] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers", - RFC 4635, August 2006. - -8.2. Informative References - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 - (SHA1)", RFC 3174, September 2001. - - [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., - and R. Hall, "Generic Security Service Algorithm for - Secret Key Transaction Authentication for DNS (GSS-TSIG)", - RFC 3645, October 2003. - - [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", - RFC 3874, September 2004. - - [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms - (SHA and HMAC-SHA)", RFC 4634, July 2006. - - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 5226, BCP 26, - May 2008. - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 5] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - -Author's Address - - Francis Dupont - ISC - - Email: Francis.Dupont@fdupont.fr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 6] - diff --git a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt deleted file mode 100644 index f64e8dd572e..00000000000 --- a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt +++ /dev/null @@ -1,952 +0,0 @@ - - - -DNSOP W. Hardaker -Internet-Draft Sparta, Inc. -Intended status: Informational February 12, 2009 -Expires: August 16, 2009 - - - Requirements for Management of Name Servers for the DNS - draft-ietf-dnsop-name-server-management-reqs-02.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2009. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. - -Abstract - - Management of name servers for the Domain Name Service (DNS) has - traditionally been done using vendor-specific monitoring, - - - -Hardaker Expires August 16, 2009 [Page 1] - -Internet-Draft Name Server Management Requirements February 2009 - - - configuration and control methods. Although some service monitoring - platforms can test the functionality of the DNS itself there is not a - interoperable way to manage (monitor, control and configure) the - internal aspects of a name server itself. - - This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 - 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 - 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5 - 2. Management Architecture Requirements . . . . . . . . . . . . . 5 - 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5 - 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5 - 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6 - 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6 - 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6 - 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6 - 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7 - 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7 - 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7 - 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8 - 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8 - 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8 - 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9 - 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9 - 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9 - 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9 - 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9 - 3.2.5. DNS Protocol Authorization Management . . . . . . . . 9 - 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 - 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10 - 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 - 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11 - 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11 - 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 - 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11 - 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12 - 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13 - 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13 - 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13 - - - -Hardaker Expires August 16, 2009 [Page 2] - -Internet-Draft Name Server Management Requirements February 2009 - - - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15 - A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16 - A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16 - A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 16, 2009 [Page 3] - -Internet-Draft Name Server Management Requirements February 2009 - - -1. Introduction - - Management of name servers for the Domain Name Service (DNS) - [RFC1034] [RFC1035] has traditionally been done using vendor-specific - monitoring, configuration and control methods. Although some service - monitoring platforms can test the functionality of the DNS itself - there is not a interoperable way to manage (monitor, control and - configure) the internal aspects of a name server itself. - - Previous standardization work within the IETF resulted in the - creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed - to achieve significant implementation and deployment. The perceived - reasons behind the failure for the two MIB modules are further - documented in [RFC3197]. - - This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. - - Specifically out of scope for this document are requirements - associated with management of stub resolvers. It is not the intent - of this document to document stub resolver requirements, although - some of the requirements listed are applicable to stub resolvers as - well. - - Also out of scope for this document is management of the host or - other components of the host upon which the name server software is - running. This document only discusses requirements for managing the - name server component of a system. - - The task of creating a management system for managing DNS servers is - not expected to be a small one. It is likely that components of the - solution will need to be designed in parts over time and these - requirements take this into consideration. In particular, - Section 5.1 discusses the need for future extensibility of the base - management solution. This document is intended to be a road-map - towards a desired outcome and is not intended to define an "all-or- - nothing" system. Successful interoperable management of name servers - even in part is expected to be beneficial to network operators - compared to the entirely custom solutions that are used at the time - of this writing. - -1.1. Requirements notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - -Hardaker Expires August 16, 2009 [Page 4] - -Internet-Draft Name Server Management Requirements February 2009 - - -1.1.1. Terminology - - This document is consistent with the terminology defined in Section 2 - of [RFC4033]. Additional terminology needed for this document is - described below: - - Name Server: When we are discussing servers that don't fall into a - more specific type of server category defined in other documents, - this document will refer to them generically as "name servers". - In particular "name servers" can be considered to be any valid - combination of authoritative, recursive, validating, or security- - aware. The more specific name server labels will be used when - this document refers only to a specific type of server. However, - the term "name server", in this document, will not include stub - resolvers. - -1.1.2. Document Layout and Requirements - - The document is written so that each numbered section will contain - only a single requirement if it contains one at all. Each - requirement will contain needed wording from the terminology - described in Section 1.1. Subsections, however, might exist with - additional related requirements. The document is laid out in this - way so that a specific requirement can be uniquely referred to using - the section number itself and the document version from which it - came. - - -2. Management Architecture Requirements - - This section discusses requirements that reflect the needs of the - expected deployment environments. - -2.1. Expected Deployment Scenarios - - DNS zones vary greatly in the type of content published within them. - Name Servers, too, are deployed with a wide variety of configurations - to support the diversity of the deployed content. It is important - that a management solution trying to meet the criteria specified in - this document consider supporting the largest number of potential - deployment cases as possible. Further deployment scenarios that are - not used as direct examples of specific requirements are listed in - Appendix A. - -2.1.1. Zone Size Constraints - - The management solution MUST support both name servers that are - serving a small number of potentially very large zones (e.g. Top - - - -Hardaker Expires August 16, 2009 [Page 5] - -Internet-Draft Name Server Management Requirements February 2009 - - - Level Domains (TLDs)) as well as name servers that are serving a very - large number of small zones. These scenarios are both commonly seen - deployments. - -2.1.2. Name Server Discovery - - Large enterprise network deployments may contain multiple name - servers operating within the boundaries of the enterprise network. - These name servers may each be serving multiple zones both in and out - of the parent enterprise's zone. Finding and managing large - quantities of name servers would be a useful feature of the resulting - management solution. The management solution MAY support the ability - to discover previously unknown instances of name servers operating - within a deployed network. - -2.1.3. Configuration Data Volatility - - Configuration data is defined as data that relates only to the - configuration of a server and the zones it serves. It specifically - does not include data from the zone contents that is served through - DNS itself. The solution MUST support servers that remain fairly - statically configured over time as well as servers that have numerous - zones being added and removed within an hour. Both of these - scenarios are also commonly seen deployments. - -2.1.4. Protocol Selection - - There are many requirements in this document for many different types - of management operations (see Section 3 for further details). It is - possible that no one protocol will ideally fill all the needs of the - requirements listed in this document and thus multiple protocols - might be needed to produce a completely functional management system. - Multiple protocols might be used to create the complete management - solution, but the number of protocols used SHOULD be reduced to a - reasonable minimum number. - -2.1.5. Common Data Model - - Defining a standardized protocol (or set of protocols) to use for - managing name servers would be a step forward in achieving an - interoperable management solution. However, just defining a protocol - to use by itself would not achieve the complete end goal of a - complete interoperable management solution. Devices also need to - represent their internal management interface using a common - management data model. The solution MUST create a common data model - that management stations can make use of when sending or collecting - data from a managed device so it can successfully manage equipment - from vendors as if they were generic DNS servers. This common data - - - -Hardaker Expires August 16, 2009 [Page 6] - -Internet-Draft Name Server Management Requirements February 2009 - - - model is needed for of the operations discussion in Section 3. Note - that this does not preclude the fact that name server vendors might - provide additional management infrastructure beyond a base management - specification, as discussed further in Section 5.1. - -2.1.6. Operational Impact - - It is impossible to add new features to an existing server (such as - the inclusion of a management infrastructure) and not impact the - existing service and/or server in some fashion. At a minimum, for - example, more memory, disk and/or CPU resources will be required to - implement a new management system. However, the impact to the - existing DNS service MUST be minimized since the DNS service itself - is still the primary service to be offered by the modified name - server. - -2.2. Name Server Types - - There are multiple ways in which name servers can be deployed. Name - servers can take on any of the following roles: - - o Master Servers - - o Slave Servers - - o Recursive Servers - - The management solution SHOULD support all of these types of name - servers as they are all equally important. Note that "Recursive - Servers" can be further broken down by the security sub-roles they - might implement, as defined in section 2 of [RFC4033]. These sub- - roles are also important to support within any management solution. - - As stated earlier, the management of stub resolvers is considered out - of scope for this documents. - - -3. Management Operation Types - - Management operations can traditionally be broken into four - categories: - - o Control - - o Configuration - - o Health and Monitoring - - - - -Hardaker Expires August 16, 2009 [Page 7] - -Internet-Draft Name Server Management Requirements February 2009 - - - o Alarms and Events - - This section discusses requirements for each of these four management - types in detail. - -3.1. Control Requirements - - The management solution MUST be capable of performing basic service - control operations. - -3.1.1. Needed Control Operations - - These operations SHOULD include, at a minimum, the following - operations: - - o Starting the name server - - o Reloading the service configuration - - o Reloading zone data - - o Restarting the name server - - o Stopping the name server - - Note that no restriction is placed on how the management system - implements these operations. In particular, at least "starting the - name server" will require a minimal management system component to - exist independently of the name server itself. - -3.1.2. Asynchronous Status Notifications - - Some control operations might take a long time to complete. As an - example, some name servers take a long time to perform reloads of - large zones. Because of these timing issues, the management solution - SHOULD take this into consideration and offer a mechanism to ease the - burden associated with awaiting the status of a long-running command. - This could, for example, result in the use of asynchronous - notifications for returning the status of a long-running task or it - might require the management station to poll for the status of a - given task using monitoring commands. These and other potential - solutions need to be evaluated carefully to select one that balances - the result delivery needs with the perceived implementation costs. - - Also, see the related discussion in Section 3.4 on notification - messages for supporting delivery of alarm and event messages. - - - - - -Hardaker Expires August 16, 2009 [Page 8] - -Internet-Draft Name Server Management Requirements February 2009 - - -3.2. Configuration Requirements - - Many features of name servers need to be configured before the server - can be considered functional. The management solution MUST be able - to provide name servers with configuration data. The most important - data to be configured, for example, is the served zone data itself. - -3.2.1. Served Zone Modification - - The ability to add, modify and delete zones being served by name - servers is needed. Although there are already solutions for zone - content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], - AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that - might be used as part of the final management solution, the - management system SHOULD still be able to natively create a new zone - (with enough minimal data to allow the other mechanisms to function - as well) as well as delete a zone. This might be, for example, a - management operation that at least allows for the creation of the - initial SOA record for a new zone as that's the minimum amount of - zone data needed for the other operations to function. - -3.2.2. Trust Anchor Management - - The solution SHOULD support the ability to add, modify and delete - trust anchors that are used by DNS Security (DNSSEC) [RFC4033] - [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust - anchors might be configured using the data from the DNSKEY Resource - Records (RRs) themselves or by using Delegation Signer (DS) - fingerprints. - -3.2.3. Security Expectations - - DNSSEC Validating resolvers need to make policy decisions about the - requests being processed. For example, they need to be configured - with a list of zones expected to be secured by DNSSEC. The - management solution SHOULD be able to add, modify and delete - attributes of DNSSEC security policies. - -3.2.4. TSIG Key Management - - TSIG [RFC2845] allows transaction level authentication of DNS - traffic. The management solution SHOULD be able to add, modify and - delete TSIG keys known to the name server. - -3.2.5. DNS Protocol Authorization Management - - The management solution SHOULD have the ability to add, modify and - delete authorization settings for the DNS protocols itself. Do not - - - -Hardaker Expires August 16, 2009 [Page 9] - -Internet-Draft Name Server Management Requirements February 2009 - - - confuse this with the ability to manage the authorization associated - with the management protocol itself, which is discussed later in - Section 4.4. There are a number of authorization settings that are - used by a name server. Example authorization settings that the - solution might need to cover are: - - o Access to operations on zone data (e.g. DDNS) - - o Access to certain zone data from certain sources (e.g. from - particular network subnets) - - o Access to specific DNS protocol services (e.g. recursive service) - - Note: the above list is expected to be used as a collection of - examples and is not a complete list of needed authorization - protections. - -3.3. Monitoring Requirements - - Monitoring is the process of collecting aspects of the internal state - of a name server at a given moment in time. The solution MUST be - able to monitor the health of a name server to determine its - operational status, load and other internal attributes. Example - management tasks that the solution might need to cover are: - - o Number of requests sent, responses sent, average response latency - and other performance counters - - o Server status (e.g. "serving data", "starting up", "shutting - down", ...) - - o Access control violations - - o List of zones being served - - o Detailed statistics about clients interacting with the name server - (e.g. top 10 clients requesting data). - - Note: the above list is expected to be used as a collection of - examples and is not a complete list of needed monitoring operations. - In particular, some monitoring statistics are expected to be - computationally or resource expensive and are considered to be "nice - to haves" as opposed to "necessary to have". - -3.4. Alarm and Event Requirements - - Events occurring at the name server that trigger alarm notifications - can quickly inform a management station about critical issues. A - - - -Hardaker Expires August 16, 2009 [Page 10] - -Internet-Draft Name Server Management Requirements February 2009 - - - management solution SHOULD include support for delivery of alarm - conditions. - - Example alarm conditions might include: - - o The server's status is changing. (e.g it is starting up, reloading - configuration, restarting or shutting down) - - o A needed resource (e.g. memory or disk space) is exhausted or - nearing exhaustion - - o An authorization violation was detected - - o The server has not received any data traffic (e.g. DNS requests - or NOTIFYs) recently (AKA the "lonely warning"). This condition - might indicate a problem with its deployment. - - -4. Security Requirements - - The management solution will need to be appropriately secured against - attacks on the management infrastructure. - -4.1. Authentication - - The solution MUST support mutual authentication. The management - client needs to be assured that the management operations are being - transferred to and from the correct name server. The managed name - server needs to authenticate the system that is accessing the - management infrastructure within itself. - -4.2. Integrity Protection - - Management operations MUST be protected from modification while in - transit from the management client to the server. - -4.3. Confidentiality - - The management solution MUST support message confidentiality. The - potential transfer of sensitive configuration is expected (such as - TSIG keys or security policies). The solution does not, however, - necessarily need to provide confidentiality to data that would - normally be carried without confidentiality by the DNS system itself. - -4.4. Authorization - - The solution SHOULD be capable of providing a fine-grained - authorization model for any management protocols it introduces to the - - - -Hardaker Expires August 16, 2009 [Page 11] - -Internet-Draft Name Server Management Requirements February 2009 - - - completed system. This authorization differs from the authorization - previously discussed in Section 3.2.5 in that this requirement is - concerned solely with authorization of the management system itself. - - There are a number of authorization settings that might be used by a - managed system to determine whether the managing entity has - authorization to perform the given management task. Example - authorization settings that the solution might need to cover are: - - o Access to the configuration that specifies which zones are to be - served - - o Access to the management system infrastructure - - o Access to other control operations - - o Access to other configuration operations - - o Access to monitoring operations - - Note: the above list is expected to be used as a collection of - examples and is not a complete list of needed authorization - protections. - -4.5. Solution Impacts on Security - - The solution MUST minimize the security risks introduced to the - complete name server system. It is impossible to add new - infrastructure to a server and not impact the security in some - fashion as the introduction of a management protocol alone will - provide a new avenue for potential attack. Although the added - management benefits will be worth the increased risks, the solution - still needs to minimize this impact as much as possible. - - -5. Other Requirements - -5.1. Extensibility - - The management solution is expected to change and expand over time as - lessons are learned and new DNS features are deployed. Thus, the - solution MUST be flexible and be able to accommodate new future - management operations. The solution might, for example, make use of - protocol versioning or capability description exchanges to ensure - that management stations and name servers that weren't written to the - same specification version can still interoperate to the best of - their combined ability. - - - - -Hardaker Expires August 16, 2009 [Page 12] - -Internet-Draft Name Server Management Requirements February 2009 - - -5.1.1. Vendor Extensions - - It MUST be possible for vendors to extend the standardized management - model with vendor-specific extensions to support additional features - offered by their products. - -5.1.2. Extension Identification - - It MUST be possible for a management station to understand which - parts of returned data are specific to a given vendor or other - standardized extension. The data returned needs to be appropriately - marked through the use of name spaces or similar mechanisms to ensure - that the base management model data can be logically separated from - extension data without needing to understand the extension data - itself. - -5.1.3. Name-Space Collision Protection - - It MUST be possible to protect against multiple extensions - conflicting with each other. The use of name-space protection - mechanisms for communicated management variables is common practice - to protect against problems. Name-space identification techniques - also frequently solve the "Extension Identification" requirement - discussed in Section 5.1.2 as well. - - -6. Security Considerations - - Any management protocol that meets the criteria discussed in this - document needs to support the criteria discussed in Section 4 in - order to protect the management infrastructure itself. The DNS is a - core Internet service and management traffic that protects it could - be the target of attacks designed to subvert that service. Because - the management infrastructure will be adding additional interfaces to - that service, it is critical that the management infrastructure - support adequate protections against network attacks. - - -7. IANA Considerations - - No action is required from IANA for this document. - - -8. Document History - - A requirement gathering discussion was held at the December 2007 IETF - meeting in Vancouver, BC, Canada and a follow up meeting was held at - the March 2008 IETF meeting in Philadelphia. This document is a - - - -Hardaker Expires August 16, 2009 [Page 13] - -Internet-Draft Name Server Management Requirements February 2009 - - - compilation of the results of those discussions as well as - discussions on the DCOMA mailing list. - - -9. Acknowledgments - - This draft is the result of discussions within the DCOMA design team - chaired by Jaap Akkerhuis. This team consisted of a large number of - people all of whom provided valuable insight and input into the - discussions surrounding name server management. The text of this - document was written from notes taken during meetings as well as from - contributions sent to the DCOMA mailing list. This work documents - the consensus of the DCOMA design team. - - In particular, the following team members contributed significantly - to the text in the document: - - Stephane Bortzmeyer - - Stephen Morris - - Phil Regnauld - - Further editing contributions and wording suggestions were made by: - Alfred Hoenes. - - -10. References - -10.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - - - -Hardaker Expires August 16, 2009 [Page 14] - -Internet-Draft Name Server Management Requirements February 2009 - - - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006. - - [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) - Trust Anchors", RFC 5011, September 2007. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - -10.2. Informative References - - [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", - RFC 1611, May 1994. - - [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", - RFC 1612, May 1994. - - [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. - - [RFC3197] Austein, R., "Applicability Statement for DNS MIB - Extensions", RFC 3197, November 2001. - - -Appendix A. Deployment Scenarios - - This appendix documents some additional deployment scenarios that - have been traditionally difficult to manage. They are provided as - - - -Hardaker Expires August 16, 2009 [Page 15] - -Internet-Draft Name Server Management Requirements February 2009 - - - guidance to protocol developers as data points of real-world name - server management problems. - -A.1. Non-Standard Zones - - If an organization uses non-standard zones (for example a purely- - local TLD), synchronizing all the name servers for these zones is - usually a time-consuming task. It is made worse when two - organizations with conflicting zones merge. This situation is not a - recommended deployment scenario (and is even heavily discouraged) but - it is, unfortunately, seen in the wild. - - It is typically implemented using "forwarding" zones. But there is - no way to ensure automatically that all the resolvers have the same - set of zones to forward at any given time. New zones might be added - to a local forwarding recursive server, for example, without - modifying the rest of the deployed forwarding servers. It is hoped - that a management solution which could handle the configuration of - zone forwarding would finally allow management of servers deployed in - this fashion. - -A.2. Redundancy Sharing - - For reliability reasons it is recommended that zone operators follow - the guidelines documented in [RFC2182] which recommends that multiple - name servers be configured for each zone and that the name servers - are separated both physically and via connectivity routes. A common - solution is to establish DNS-serving partnerships: "I'll host your - zones and you'll host mine". Both entities benefit from increased - DNS reliability via the wider service distribution. This frequently - occurs between cooperating but otherwise unrelated entities (such as - between two distinct companies) as well as between affiliated - organizations (such as between branch offices within a single - company). - - The configuration of these relationships are currently required to be - manually configured and maintained. Changes to the list of zones - that are cross-hosted are manually negotiated between the cooperating - network administrators and configured by hand. A management protocol - with the ability to provide selective authorization, as discussed in - Section 4.4, would solve many of the management difficulties between - cooperating organizations. - -A.3. DNSSEC Management - - There are many different DNSSEC deployment strategies that may be - used for mission-critical zones. The following list describes some - example deployment scenarios that might warrant different management - - - -Hardaker Expires August 16, 2009 [Page 16] - -Internet-Draft Name Server Management Requirements February 2009 - - - strategies. - - All contents and DNSSEC keying information controlled and operated - by a single organization - - Zone contents controlled and operated by one organization, all - DNSSEC keying information controlled and operated by a second - organization. - - Zone contents controlled and operated by one organization, zone - signing keys (ZSKs) controlled and operated by a second - organization, and key signing keys (KSKs) controlled and operated - by a third organization. - - Although this list is not exhaustive in the potential ways that zone - data can be divided up, it should be sufficient to illustrate the - potential ways in which zone data can be controlled by multiple - entities. - - The end result of all of these strategies, however, will be the same: - a live zone containing DNSSEC related resource records. Many of the - above strategies are merely different ways of preparing a zone for - serving. A management solution that includes support for managing - DNSSEC zone data may wish to take into account these potential - management scenarios. - - -Author's Address - - Wes Hardaker - Sparta, Inc. - P.O. Box 382 - Davis, CA 95617 - US - - Phone: +1 530 792 1913 - Email: ietf@hardakers.net - - - - - - - - - - - - - - -Hardaker Expires August 16, 2009 [Page 17] - diff --git a/doc/rfc/rfc1912.txt b/doc/rfc/rfc1912.txt deleted file mode 100644 index 8ace7d26748..00000000000 --- a/doc/rfc/rfc1912.txt +++ /dev/null @@ -1,899 +0,0 @@ - - - - - - -Network Working Group D. Barr -Request for Comments: 1912 The Pennsylvania State University -Obsoletes: 1537 February 1996 -Category: Informational - - - Common DNS Operational and Configuration Errors - -Status of this Memo - - This memo provides information for the Internet community. This memo - does not specify an Internet standard of any kind. Distribution of - this memo is unlimited. - -Abstract - - This memo describes errors often found in both the operation of - Domain Name System (DNS) servers, and in the data that these DNS - servers contain. This memo tries to summarize current Internet - requirements as well as common practice in the operation and - configuration of the DNS. This memo also tries to summarize or - expand upon issues raised in [RFC 1537]. - -1. Introduction - - Running a nameserver is not a trivial task. There are many things - that can go wrong, and many decisions have to be made about what data - to put in the DNS and how to set up servers. This memo attempts to - address many of the common mistakes and pitfalls that are made in DNS - data as well as in the operation of nameservers. Discussions are - also made regarding some other relevant issues such as server or - resolver bugs, and a few political issues with respect to the - operation of DNS on the Internet. - -2. DNS Data - - This section discusses problems people typically have with the DNS - data in their nameserver, as found in the zone data files that the - nameserver loads into memory. - -2.1 Inconsistent, Missing, or Bad Data - - Every Internet-reachable host should have a name. The consequences - of this are becoming more and more obvious. Many services available - on the Internet will not talk to you if you aren't correctly - registered in the DNS. - - - - - -Barr Informational [Page 1] - -RFC 1912 Common DNS Errors February 1996 - - - Make sure your PTR and A records match. For every IP address, there - should be a matching PTR record in the in-addr.arpa domain. If a - host is multi-homed, (more than one IP address) make sure that all IP - addresses have a corresponding PTR record (not just the first one). - Failure to have matching PTR and A records can cause loss of Internet - services similar to not being registered in the DNS at all. Also, - PTR records must point back to a valid A record, not a alias defined - by a CNAME. It is highly recommended that you use some software - which automates this checking, or generate your DNS data from a - database which automatically creates consistent data. - - DNS domain names consist of "labels" separated by single dots. The - DNS is very liberal in its rules for the allowable characters in a - domain name. However, if a domain name is used to name a host, it - should follow rules restricting host names. Further if a name is - used for mail, it must follow the naming rules for names in mail - addresses. - - Allowable characters in a label for a host name are only ASCII - letters, digits, and the `-' character. Labels may not be all - numbers, but may have a leading digit (e.g., 3com.com). Labels must - end and begin only with a letter or digit. See [RFC 1035] and [RFC - 1123]. (Labels were initially restricted in [RFC 1035] to start with - a letter, and some older hosts still reportedly have problems with - the relaxation in [RFC 1123].) Note there are some Internet - hostnames which violate this rule (411.org, 1776.com). The presence - of underscores in a label is allowed in [RFC 1033], except [RFC 1033] - is informational only and was not defining a standard. There is at - least one popular TCP/IP implementation which currently refuses to - talk to hosts named with underscores in them. It must be noted that - the language in [1035] is such that these rules are voluntary -- they - are there for those who wish to minimize problems. Note that the - rules for Internet host names also apply to hosts and addresses used - in SMTP (See RFC 821). - - If a domain name is to be used for mail (not involving SMTP), it must - follow the rules for mail in [RFC 822], which is actually more - liberal than the above rules. Labels for mail can be any ASCII - character except "specials", control characters, and whitespace - characters. "Specials" are specific symbols used in the parsing of - addresses. They are the characters "()<>@,;:\".[]". (The "!" - character wasn't in [RFC 822], however it also shouldn't be used due - to the conflict with UUCP mail as defined in RFC 976) However, since - today almost all names which are used for mail on the Internet are - also names used for hostnames, one rarely sees addresses using these - relaxed standard, but mail software should be made liberal and robust - enough to accept them. - - - - -Barr Informational [Page 2] - -RFC 1912 Common DNS Errors February 1996 - - - You should also be careful to not have addresses which are valid - alternate syntaxes to the inet_ntoa() library call. For example 0xe - is a valid name, but if you were to type "telnet 0xe", it would try - to connect to IP address 0.0.0.14. It is also rumored that there - exists some broken inet_ntoa() routines that treat an address like - x400 as an IP address. - - Certain operating systems have limitations on the length of their own - hostname. While not strictly of issue to the DNS, you should be - aware of your operating system's length limits before choosing the - name of a host. - - Remember that many resource records (abbreviated RR) take on more - than one argument. HINFO requires two arguments, as does RP. If you - don't supply enough arguments, servers sometime return garbage for - the missing fields. If you need to include whitespace within any - data, you must put the string in quotes. - -2.2 SOA records - - In the SOA record of every zone, remember to fill in the e-mail - address that will get to the person who maintains the DNS at your - site (commonly referred to as "hostmaster"). The `@' in the e-mail - must be replaced by a `.' first. Do not try to put an `@' sign in - this address. If the local part of the address already contains a - `.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by - preceding it with `\' character. (e.g., to become - John\.Smith.widget.xx) Alternately (and preferred), you can just use - the generic name `hostmaster', and use a mail alias to redirect it to - the appropriate persons. There exists software which uses this field - to automatically generate the e-mail address for the zone contact. - This software will break if this field is improperly formatted. It - is imperative that this address get to one or more real persons, - because it is often used for everything from reporting bad DNS data - to reporting security incidents. - - Even though some BIND versions allow you to use a decimal in a serial - number, don't. A decimal serial number is converted to an unsigned - 32-bit integer internally anyway. The formula for a n.m serial - number is n*10^(3+int(0.9+log10(m))) + m which translates to - something rather unexpected. For example it's routinely possible - with a decimal serial number (perhaps automatically generated by - SCCS) to be incremented such that it is numerically larger, but after - the above conversion yield a serial number which is LOWER than - before. Decimal serial numbers have been officially deprecated in - recent BIND versions. The recommended syntax is YYYYMMDDnn - (YYYY=year, MM=month, DD=day, nn=revision number. This won't - overflow until the year 4294. - - - -Barr Informational [Page 3] - -RFC 1912 Common DNS Errors February 1996 - - - Choose logical values for the timer values in the SOA record (note - values below must be expressed as seconds in the zone data): - - Refresh: How often a secondary will poll the primary server to see - if the serial number for the zone has increased (so it knows - to request a new copy of the data for the zone). Set this to - how long your secondaries can comfortably contain out-of-date - data. You can keep it short (20 mins to 2 hours) if you - aren't worried about a small increase in bandwidth used, or - longer (2-12 hours) if your Internet connection is slow or is - started on demand. Recent BIND versions (4.9.3) have optional - code to automatically notify secondaries that data has - changed, allowing you to set this TTL to a long value (one - day, or more). - - Retry: If a secondary was unable to contact the primary at the - last refresh, wait the retry value before trying again. This - value isn't as important as others, unless the secondary is on - a distant network from the primary or the primary is more - prone to outages. It's typically some fraction of the refresh - interval. - - - Expire: How long a secondary will still treat its copy of the zone - data as valid if it can't contact the primary. This value - should be greater than how long a major outage would typically - last, and must be greater than the minimum and retry - intervals, to avoid having a secondary expire the data before - it gets a chance to get a new copy. After a zone is expired a - secondary will still continue to try to contact the primary, - but it will no longer provide nameservice for the zone. 2-4 - weeks are suggested values. - - Minimum: The default TTL (time-to-live) for resource records -- - how long data will remain in other nameservers' cache. ([RFC - 1035] defines this to be the minimum value, but servers seem - to always implement this as the default value) This is by far - the most important timer. Set this as large as is comfortable - given how often you update your nameserver. If you plan to - make major changes, it's a good idea to turn this value down - temporarily beforehand. Then wait the previous minimum value, - make your changes, verify their correctness, and turn this - value back up. 1-5 days are typical values. Remember this - value can be overridden on individual resource records. - - - - - - - -Barr Informational [Page 4] - -RFC 1912 Common DNS Errors February 1996 - - - As you can see, the typical values above for the timers vary widely. - Popular documentation like [RFC 1033] recommended a day for the - minimum TTL, which is now considered too low except for zones with - data that vary regularly. Once a DNS stabilizes, values on the order - of 3 or more days are recommended. It is also recommended that you - individually override the TTL on certain RRs which are often - referenced and don't often change to have very large values (1-2 - weeks). Good examples of this are the MX, A, and PTR records of your - mail host(s), the NS records of your zone, and the A records of your - nameservers. - -2.3 Glue A Records - - Glue records are A records that are associated with NS records to - provide "bootstrapping" information to the nameserver. For example: - - podunk.xx. in ns ns1.podunk.xx. - in ns ns2.podunk.xx. - ns1.podunk.xx. in a 1.2.3.4 - ns2.podunk.xx. in a 1.2.3.5 - - Here, the A records are referred to as "Glue records". - - Glue records are required only in forward zone files for nameservers - that are located in the subdomain of the current zone that is being - delegated. You shouldn't have any A records in an in-addr.arpa zone - file (unless you're using RFC 1101-style encoding of subnet masks). - - If your nameserver is multi-homed (has more than one IP address), you - must list all of its addresses in the glue to avoid cache - inconsistency due to differing TTL values, causing some lookups to - not find all addresses for your nameserver. - - Some people get in the bad habit of putting in a glue record whenever - they add an NS record "just to make sure". Having duplicate glue - records in your zone files just makes it harder when a nameserver - moves to a new IP address, or is removed. You'll spend hours trying - to figure out why random people still see the old IP address for some - host, because someone forgot to change or remove a glue record in - some other file. Newer BIND versions will ignore these extra glue - records in local zone files. - - Older BIND versions (4.8.3 and previous) have a problem where it - inserts these extra glue records in the zone transfer data to - secondaries. If one of these glues is wrong, the error can be - propagated to other nameservers. If two nameservers are secondaries - for other zones of each other, it's possible for one to continually - pass old glue records back to the other. The only way to get rid of - - - -Barr Informational [Page 5] - -RFC 1912 Common DNS Errors February 1996 - - - the old data is to kill both of them, remove the saved backup files, - and restart them. Combined with that those same versions also tend - to become infected more easily with bogus data found in other non- - secondary nameservers (like the root zone data). - -2.4 CNAME records - - A CNAME record is not allowed to coexist with any other data. In - other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you - can't also have an MX record for suzy.podunk.edu, or an A record, or - even a TXT record. Especially do not try to combine CNAMEs and NS - records like this!: - - - podunk.xx. IN NS ns1 - IN NS ns2 - IN CNAME mary - mary IN A 1.2.3.4 - - - This is often attempted by inexperienced administrators as an obvious - way to allow your domain name to also be a host. However, DNS - servers like BIND will see the CNAME and refuse to add any other - resources for that name. Since no other records are allowed to - coexist with a CNAME, the NS entries are ignored. Therefore all the - hosts in the podunk.xx domain are ignored as well! - - If you want to have your domain also be a host, do the following: - - podunk.xx. IN NS ns1 - IN NS ns2 - IN A 1.2.3.4 - mary IN A 1.2.3.4 - - Don't go overboard with CNAMEs. Use them when renaming hosts, but - plan to get rid of them (and inform your users). However CNAMEs are - useful (and encouraged) for generalized names for servers -- `ftp' - for your ftp server, `www' for your Web server, `gopher' for your - Gopher server, `news' for your Usenet news server, etc. - - Don't forget to delete the CNAMEs associated with a host if you - delete the host it is an alias for. Such "stale CNAMEs" are a waste - of resources. - - - - - - - - -Barr Informational [Page 6] - -RFC 1912 Common DNS Errors February 1996 - - - Don't use CNAMEs in combination with RRs which point to other names - like MX, CNAME, PTR and NS. (PTR is an exception if you want to - implement classless in-addr delegation.) For example, this is - strongly discouraged: - - podunk.xx. IN MX mailhost - mailhost IN CNAME mary - mary IN A 1.2.3.4 - - - [RFC 1034] in section 3.6.2 says this should not be done, and [RFC - 974] explicitly states that MX records shall not point to an alias - defined by a CNAME. This results in unnecessary indirection in - accessing the data, and DNS resolvers and servers need to work more - to get the answer. If you really want to do this, you can accomplish - the same thing by using a preprocessor such as m4 on your host files. - - Also, having chained records such as CNAMEs pointing to CNAMEs may - make administration issues easier, but is known to tickle bugs in - some resolvers that fail to check loops correctly. As a result some - hosts may not be able to resolve such names. - - Having NS records pointing to a CNAME is bad and may conflict badly - with current BIND servers. In fact, current BIND implementations - will ignore such records, possibly leading to a lame delegation. - There is a certain amount of security checking done in BIND to - prevent spoofing DNS NS records. Also, older BIND servers reportedly - will get caught in an infinite query loop trying to figure out the - address for the aliased nameserver, causing a continuous stream of - DNS requests to be sent. - -2.5 MX records - - It is a good idea to give every host an MX record, even if it points - to itself! Some mailers will cache MX records, but will always need - to check for an MX before sending mail. If a site does not have an - MX, then every piece of mail may result in one more resolver query, - since the answer to the MX query often also contains the IP addresses - of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to - support the MX mechanism. - - Put MX records even on hosts that aren't intended to send or receive - e-mail. If there is a security problem involving one of these hosts, - some people will mistakenly send mail to postmaster or root at the - site without checking first to see if it is a "real" host or just a - terminal or personal computer that's not set up to accept e-mail. If - you give it an MX record, then the e-mail can be redirected to a real - person. Otherwise mail can just sit in a queue for hours or days - - - -Barr Informational [Page 7] - -RFC 1912 Common DNS Errors February 1996 - - - until the mailer gives up trying to send it. - - Don't forget that whenever you add an MX record, you need to inform - the target mailer if it is to treat the first host as "local". (The - "Cw" flag in sendmail, for example) - - If you add an MX record which points to an external host (e.g., for - the purposes of backup mail routing) be sure to ask permission from - that site first. Otherwise that site could get rather upset and take - action (like throw your mail away, or appeal to higher authorities - like your parent DNS administrator or network provider.) - -2.6 Other Resource Records - -2.6.1 WKS - - WKS records are deprecated in [RFC 1123]. They serve no known useful - function, except internally among LISP machines. Don't use them. - -2.6.2 HINFO - - On the issue HINFO records, some will argue that these is a security - problem (by broadcasting what vendor hardware and operating system - you so people can run systematic attacks on known vendor security - holes). If you do use them, you should keep up to date with known - vendor security problems. However, they serve a useful purpose. - Don't forget that HINFO requires two arguments, the hardware type, - and the operating system. - - HINFO is sometimes abused to provide other information. The record - is meant to provide specific information about the machine itself. - If you need to express other information about the host in the DNS, - use TXT. - -2.6.3 TXT - - TXT records have no specific definition. You can put most anything - in them. Some use it for a generic description of the host, some put - specific information like its location, primary user, or maybe even a - phone number. - -2.6.4 RP - - RP records are relatively new. They are used to specify an e-mail - address (see first paragraph of section 2.2) of the "Responsible - Person" of the host, and the name of a TXT record where you can get - more information. See [RFC 1183]. - - - - -Barr Informational [Page 8] - -RFC 1912 Common DNS Errors February 1996 - - -2.7 Wildcard records - - Wildcard MXs are useful mostly for non IP-connected sites. A common - mistake is thinking that a wildcard MX for a zone will apply to all - hosts in the zone. A wildcard MX will apply only to names in the - zone which aren't listed in the DNS at all. e.g., - - podunk.xx. IN NS ns1 - IN NS ns2 - mary IN A 1.2.3.4 - *.podunk.xx. IN MX 5 sue - - Mail for mary.podunk.xx will be sent to itself for delivery. Only - mail for jane.podunk.xx or any hosts you don't see above will be sent - to the MX. For most Internet sites, wildcard MX records are not - useful. You need to put explicit MX records on every host. - - Wildcard MXs can be bad, because they make some operations succeed - when they should fail instead. Consider the case where someone in - the domain "widget.com" tries to send mail to "joe@larry". If the - host "larry" doesn't actually exist, the mail should in fact bounce - immediately. But because of domain searching the address gets - resolved to "larry.widget.com", and because of the wildcard MX this - is a valid address according to DNS. Or perhaps someone simply made - a typo in the hostname portion of the address. The mail message then - gets routed to the mail host, which then rejects the mail with - strange error messages like "I refuse to talk to myself" or "Local - configuration error". - - Wildcard MX records are good for when you have a large number of - hosts which are not directly Internet-connected (for example, behind - a firewall) and for administrative or political reasons it is too - difficult to have individual MX records for every host, or to force - all e-mail addresses to be "hidden" behind one or more domain names. - In that case, you must divide your DNS into two parts, an internal - DNS, and an external DNS. The external DNS will have only a few - hosts and explicit MX records, and one or more wildcard MXs for each - internal domain. Internally the DNS will be complete, with all - explicit MX records and no wildcards. - - Wildcard As and CNAMEs are possible too, and are really confusing to - users, and a potential nightmare if used without thinking first. It - could result (due again to domain searching) in any telnet/ftp - attempts from within the domain to unknown hosts to be directed to - one address. One such wildcard CNAME (in *.edu.com) caused - Internet-wide loss of services and potential security nightmares due - to unexpected interactions with domain searching. It resulted in - swift fixes, and even an RFC ([RFC 1535]) documenting the problem. - - - -Barr Informational [Page 9] - -RFC 1912 Common DNS Errors February 1996 - - -2.8 Authority and Delegation Errors (NS records) - - You are required to have at least two nameservers for every domain, - though more is preferred. Have secondaries outside your network. If - the secondary isn't under your control, periodically check up on them - and make sure they're getting current zone data from you. Queries to - their nameserver about your hosts should always result in an - "authoritative" response. If not, this is called a "lame - delegation". A lame delegations exists when a nameserver is - delegated responsibility for providing nameservice for a zone (via NS - records) but is not performing nameservice for that zone (usually - because it is not set up as a primary or secondary for the zone). - - The "classic" lame delegation can be illustrated in this example: - - podunk.xx. IN NS ns1.podunk.xx. - IN NS ns0.widget.com. - - "podunk.xx" is a new domain which has recently been created, and - "ns1.podunk.xx" has been set up to perform nameservice for the zone. - They haven't quite finished everything yet and haven't made sure that - the hostmaster at "ns0.widget.com" has set up to be a proper - secondary, and thus has no information about the podunk.xx domain, - even though the DNS says it is supposed to. Various things can - happen depending on which nameserver is used. At best, extra DNS - traffic will result from a lame delegation. At worst, you can get - unresolved hosts and bounced e-mail. - - Also, sometimes a nameserver is moved to another host or removed from - the list of secondaries. Unfortunately due to caching of NS records, - many sites will still think that a host is a secondary after that - host has stopped providing nameservice. In order to prevent lame - delegations while the cache is being aged, continue to provide - nameservice on the old nameserver for the length of the maximum of - the minimum plus refresh times for the zone and the parent zone. - (See section 2.2) - - Whenever a primary or secondary is removed or changed, it takes a - fair amount of human coordination among the parties involved. (The - site itself, it's parent, and the site hosting the secondary) When a - primary moves, make sure all secondaries have their named.boot files - updated and their servers reloaded. When a secondary moves, make - sure the address records at both the primary and parent level are - changed. - - It's also been reported that some distant sites like to pick popular - nameservers like "ns.uu.net" and just add it to their list of NS - records in hopes that they will magically perform additional - - - -Barr Informational [Page 10] - -RFC 1912 Common DNS Errors February 1996 - - - nameservice for them. This is an even worse form of lame delegation, - since this adds traffic to an already busy nameserver. Please - contact the hostmasters of sites which have lame delegations. - Various tools can be used to detect or actively find lame - delegations. See the list of contributed software in the BIND - distribution. - - Make sure your parent domain has the same NS records for your zone as - you do. (Don't forget your in-addr.arpa zones too!). Do not list - too many (7 is the recommended maximum), as this just makes things - harder to manage and is only really necessary for very popular top- - level or root zones. You also run the risk of overflowing the 512- - byte limit of a UDP packet in the response to an NS query. If this - happens, resolvers will "fall back" to using TCP requests, resulting - in increased load on your nameserver. - - It's important when picking geographic locations for secondary - nameservers to minimize latency as well as increase reliability. - Keep in mind network topologies. For example if your site is on the - other end of a slow local or international link, consider a secondary - on the other side of the link to decrease average latency. Contact - your Internet service provider or parent domain contact for more - information about secondaries which may be available to you. - -3. BIND operation - - This section discusses common problems people have in the actual - operation of the nameserver (specifically, BIND). Not only must the - data be correct as explained above, but the nameserver must be - operated correctly for the data to be made available. - -3.1 Serial numbers - - Each zone has a serial number associated with it. Its use is for - keeping track of who has the most current data. If and only if the - primary's serial number of the zone is greater will the secondary ask - the primary for a copy of the new zone data (see special case below). - - Don't forget to change the serial number when you change data! If - you don't, your secondaries will not transfer the new zone - information. Automating the incrementing of the serial number with - software is also a good idea. - - If you make a mistake and increment the serial number too high, and - you want to reset the serial number to a lower value, use the - following procedure: - - - - - -Barr Informational [Page 11] - -RFC 1912 Common DNS Errors February 1996 - - - Take the `incorrect' serial number and add 2147483647 to it. If - the number exceeds 4294967296, subtract 4294967296. Load the - resulting number. Then wait 2 refresh periods to allow the zone - to propagate to all servers. - - Repeat above until the resulting serial number is less than the - target serial number. - - Up the serial number to the target serial number. - - This procedure won't work if one of your secondaries is running an - old version of BIND (4.8.3 or earlier). In this case you'll have to - contact the hostmaster for that secondary and have them kill the - secondary servers, remove the saved backup file, and restart the - server. Be careful when editing the serial number -- DNS admins - don't like to kill and restart nameservers because you lose all that - cached data. - -3.2 Zone file style guide - - Here are some useful tips in structuring your zone files. Following - these will help you spot mistakes, and avoid making more. - - Be consistent with the style of entries in your DNS files. If your - $ORIGIN is podunk.xx., try not to write entries like: - - mary IN A 1.2.3.1 - sue.podunk.xx. IN A 1.2.3.2 - - or: - - bobbi IN A 1.2.3.2 - IN MX mary.podunk.xx. - - - Either use all FQDNs (Fully Qualified Domain Names) everywhere or - used unqualified names everywhere. Or have FQDNs all on the right- - hand side but unqualified names on the left. Above all, be - consistent. - - Use tabs between fields, and try to keep columns lined up. It makes - it easier to spot missing fields (note some fields such as "IN" are - inherited from the previous record and may be left out in certain - circumstances.) - - - - - - - -Barr Informational [Page 12] - -RFC 1912 Common DNS Errors February 1996 - - - Remember you don't need to repeat the name of the host when you are - defining multiple records for one host. Be sure also to keep all - records associated with a host together in the file. It will make - things more straightforward when it comes time to remove or rename a - host. - - Always remember your $ORIGIN. If you don't put a `.' at the end of - an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then - the nameserver will append $ORIGIN to the name. Double check, triple - check, those trailing dots, especially in in-addr.arpa zone files, - where they are needed the most. - - Be careful with the syntax of the SOA and WKS records (the records - which use parentheses). BIND is not very flexible in how it parses - these records. See the documentation for BIND. - -3.3 Verifying data - - Verify the data you just entered or changed by querying the resolver - with dig (or your favorite DNS tool, many are included in the BIND - distribution) after a change. A few seconds spent double checking - can save hours of trouble, lost mail, and general headaches. Also be - sure to check syslog output when you reload the nameserver. If you - have grievous errors in your DNS data or boot file, named will report - it via syslog. - - It is also highly recommended that you automate this checking, either - with software which runs sanity checks on the data files before they - are loaded into the nameserver, or with software which checks the - data already loaded in the nameserver. Some contributed software to - do this is included in the BIND distribution. - -4. Miscellaneous Topics - -4.1 Boot file setup - - Certain zones should always be present in nameserver configurations: - - primary localhost localhost - primary 0.0.127.in-addr.arpa 127.0 - primary 255.in-addr.arpa 255 - primary 0.in-addr.arpa 0 - - These are set up to either provide nameservice for "special" - addresses, or to help eliminate accidental queries for broadcast or - local address to be sent off to the root nameservers. All of these - files will contain NS and SOA records just like the other zone files - you maintain, the exception being that you can probably make the SOA - - - -Barr Informational [Page 13] - -RFC 1912 Common DNS Errors February 1996 - - - timers very long, since this data will never change. - - The "localhost" address is a "special" address which always refers to - the local host. It should contain the following line: - - localhost. IN A 127.0.0.1 - - The "127.0" file should contain the line: - - 1 PTR localhost. - - There has been some extensive discussion about whether or not to - append the local domain to it. The conclusion is that "localhost." - would be the best solution. The reasons given include: - - "localhost" by itself is used and expected to work in some - systems. - - Translating 127.0.0.1 into "localhost.dom.ain" can cause some - software to connect back to the loopback interface when it didn't - want to because "localhost" is not equal to "localhost.dom.ain". - - The "255" and "0" files should not contain any additional data beyond - the NS and SOA records. - - Note that future BIND versions may include all or some of this data - automatically without additional configuration. - -4.2 Other Resolver and Server bugs - - Very old versions of the DNS resolver have a bug that cause queries - for names that look like IP addresses to go out, because the user - supplied an IP address and the software didn't realize that it didn't - need to be resolved. This has been fixed but occasionally it still - pops up. It's important because this bug means that these queries - will be sent directly to the root nameservers, adding to an already - heavy DNS load. - - While running a secondary nameserver off another secondary nameserver - is possible, it is not recommended unless necessary due to network - topologies. There are known cases where it has led to problems like - bogus TTL values. While this may be caused by older or flawed DNS - implementations, you should not chain secondaries off of one another - since this builds up additional reliability dependencies as well as - adds additional delays in updates of new zone data. - - - - - - -Barr Informational [Page 14] - -RFC 1912 Common DNS Errors February 1996 - - -4.3 Server issues - - DNS operates primarily via UDP (User Datagram Protocol) messages. - Some UNIX operating systems, in an effort to save CPU cycles, run - with UDP checksums turned off. The relative merits of this have long - been debated. However, with the increase in CPU speeds, the - performance considerations become less and less important. It is - strongly encouraged that you turn on UDP checksumming to avoid - corrupted data not only with DNS but with other services that use UDP - (like NFS). Check with your operating system documentation to verify - that UDP checksumming is enabled. - -References - - [RFC 974] Partridge, C., "Mail routing and the domain system", STD - 14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986. - - [RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC - 1033, USC/Information Sciences Institute, November 1987. - - [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, USC/Information Sciences Institute, - November 1987. - - [RFC 1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [RFC 1123] Braden, R., "Requirements for Internet Hosts -- - Application and Support", STD 3, RFC 1123, IETF, October - 1989. - - [RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC - 1178, Integrated Systems Group/NIST, August 1990. - - [RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart, - "New DNS RR Definitions", RFC 1183, October 1990. - - [RFC 1535] Gavron, E., "A Security Problem and Proposed Correction - With Widely Deployed DNS Software", RFC 1535, ACES - Research Inc., October 1993. - - [RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. - Miller, "Common DNS Implementation Errors and Suggested - Fixes", RFC 1536, USC/Information Sciences Institute, USC, - October 1993. - - - - - -Barr Informational [Page 15] - -RFC 1912 Common DNS Errors February 1996 - - - [RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors", - RFC 1537, CWI, October 1993. - - [RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN, - November 1994. - - [BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND", - Vixie Enterprises, July 1994. - -5. Security Considerations - - Security issues are not discussed in this memo. - -6. Author's Address - - David Barr - The Pennsylvania State University - Department of Mathematics - 334 Whitmore Building - University Park, PA 16802 - - Voice: +1 814 863 7374 - Fax: +1 814 863-8311 - EMail: barr@math.psu.edu - - - - - - - - - - - - - - - - - - - - - - - - - - - -Barr Informational [Page 16] - diff --git a/doc/rfc/rfc4509.txt b/doc/rfc/rfc4509.txt deleted file mode 100644 index 4eaf296c7ba..00000000000 --- a/doc/rfc/rfc4509.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group W. Hardaker -Request for Comments: 4509 Sparta -Category: Standards Track May 2006 - - - Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) - - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document specifies how to use the SHA-256 digest type in DNS - Delegation Signer (DS) Resource Records (RRs). DS records, when - stored in a parent zone, point to DNSKEYs in a child zone. - -Table of Contents - - 1. Introduction ....................................................2 - 2. Implementing the SHA-256 Algorithm for DS Record Support ........2 - 2.1. DS Record Field Values .....................................2 - 2.2. DS Record with SHA-256 Wire Format .........................3 - 2.3. Example DS Record Using SHA-256 ............................3 - 3. Implementation Requirements .....................................3 - 4. Deployment Considerations .......................................4 - 5. IANA Considerations .............................................4 - 6. Security Considerations .........................................4 - 6.1. Potential Digest Type Downgrade Attacks ....................4 - 6.2. SHA-1 vs SHA-256 Considerations for DS Records .............5 - 7. Acknowledgements ................................................5 - 8. References ......................................................6 - 8.1. Normative References .......................................6 - 8.2. Informative References .....................................6 - - - - - - - - -Hardaker Standards Track [Page 1] - -RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 - - -1. Introduction - - The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent - zones to distribute a cryptographic digest of one key in a child's - DNSKEY RRset. The DS RRset is signed by at least one of the parent - zone's private zone data signing keys for each algorithm in use by - the parent. Each signature is published in an RRSIG resource record, - owned by the same domain as the DS RRset, with a type covered of DS. - - In this document, the key words "MUST", "MUST NOT", "REQUIRED", - "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", - and "OPTIONAL" are to be interpreted as described in [RFC2119]. - -2. Implementing the SHA-256 Algorithm for DS Record Support - - This document specifies that the digest type code 2 has been assigned - to SHA-256 [SHA256] [SHA256CODE] for use within DS records. The - results of the digest algorithm MUST NOT be truncated, and the entire - 32 byte digest result is to be published in the DS record. - -2.1. DS Record Field Values - - Using the SHA-256 digest algorithm within a DS record will make use - of the following DS-record fields: - - Digest type: 2 - - Digest: A SHA-256 bit digest value calculated by using the following - formula ("|" denotes concatenation). The resulting value is not - truncated, and the entire 32 byte result is to be used in the - resulting DS record and related calculations. - - digest = SHA_256(DNSKEY owner name | DNSKEY RDATA) - - where DNSKEY RDATA is defined by [RFC4034] as: - - DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key - - The Key Tag field and Algorithm fields remain unchanged by this - document and are specified in the [RFC4034] specification. - - - - - - - - - - - -Hardaker Standards Track [Page 2] - -RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 - - -2.2. DS Record with SHA-256 Wire Format - - The resulting on-the-wire format for the resulting DS record will be - as follows: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Key Tag | Algorithm | DigestType=2 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - / / - / Digest (length for SHA-256 is 32 bytes) / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - -2.3. Example DS Record Using SHA-256 - - The following is an example DNSKEY and matching DS record. This - DNSKEY record comes from the example DNSKEY/DS records found in - section 5.4 of [RFC4034]. - - The DNSKEY record: - - dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz - fwJr1AYtsmx3TGkJaNXVbfi/ - 2pHm822aJ5iI9BMzNXxeYCmZ - DRD99WYwYqUSdjMmmAphXdvx - egXd/M5+X7OrzKBaMbCVdFLU - Uh6DhweJBjEVv5f2wwjM9Xzc - nOf+EPbtG9DMBmADjFDc2w/r - ljwvFw== - ) ; key id = 60485 - - The resulting DS record covering the above DNSKEY record using a - SHA-256 digest: - - dskey.example.com. 86400 IN DS 60485 5 2 ( D4B7D520E7BB5F0F67674A0C - CEB1E3E0614B93C4F9E99B83 - 83F6A1E4469DA50A ) - -3. Implementation Requirements - - Implementations MUST support the use of the SHA-256 algorithm in DS - RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 - digests if DS RRs with SHA-256 digests are present in the DS RRset. - - - - - - -Hardaker Standards Track [Page 3] - -RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 - - -4. Deployment Considerations - - If a validator does not support the SHA-256 digest type and no other - DS RR exists in a zone's DS RRset with a supported digest type, then - the validator has no supported authentication path leading from the - parent to the child. The resolver should treat this case as it would - the case of an authenticated NSEC RRset proving that no DS RRset - exists, as described in [RFC4035], Section 5.2. - - Because zone administrators cannot control the deployment speed of - support for SHA-256 in validators that may be referencing any of - their zones, zone operators should consider deploying both SHA-1 and - SHA-256 based DS records. This should be done for every DNSKEY for - which DS records are being generated. Whether to make use of both - digest types and for how long is a policy decision that extends - beyond the scope of this document. - -5. IANA Considerations - - Only one IANA action is required by this document: - - The Digest Type to be used for supporting SHA-256 within DS records - has been assigned by IANA. - - At the time of this writing, the current digest types assigned for - use in DS records are as follows: - - VALUE Digest Type Status - 0 Reserved - - 1 SHA-1 MANDATORY - 2 SHA-256 MANDATORY - 3-255 Unassigned - - -6. Security Considerations - -6.1. Potential Digest Type Downgrade Attacks - - A downgrade attack from a stronger digest type to a weaker one is - possible if all of the following are true: - - o A zone includes multiple DS records for a given child's DNSKEY, - each of which uses a different digest type. - - o A validator accepts a weaker digest even if a stronger one is - present but invalid. - - - - - - -Hardaker Standards Track [Page 4] - -RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 - - - For example, if the following conditions are all true: - - o Both SHA-1 and SHA-256 based digests are published in DS records - within a parent zone for a given child zone's DNSKEY. - - o The DS record with the SHA-1 digest matches the digest computed - using the child zone's DNSKEY. - - o The DS record with the SHA-256 digest fails to match the digest - computed using the child zone's DNSKEY. - - Then, if the validator accepts the above situation as secure, then - this can be used as a downgrade attack since the stronger SHA-256 - digest is ignored. - -6.2. SHA-1 vs. SHA-256 Considerations for DS Records - - Users of DNSSEC are encouraged to deploy SHA-256 as soon as software - implementations allow for it. SHA-256 is widely believed to be more - resilient to attack than SHA-1, and confidence in SHA-1's strength is - being eroded by recently announced attacks. Regardless of whether - the attacks on SHA-1 will affect DNSSEC, it is believed (at the time - of this writing) that SHA-256 is the better choice for use in DS - records. - - At the time of this publication, the SHA-256 digest algorithm is - considered sufficiently strong for the immediate future. It is also - considered sufficient for use in DNSSEC DS RRs for the immediate - future. However, future published attacks may weaken the usability - of this algorithm within the DS RRs. It is beyond the scope of this - document to speculate extensively on the cryptographic strength of - the SHA-256 digest algorithm. - - Likewise, it is also beyond the scope of this document to specify - whether or for how long SHA-1 based DS records should be - simultaneously published alongside SHA-256 based DS records. - -7. Acknowledgements - - This document is a minor extension to the existing DNSSEC documents - and those authors are gratefully appreciated for the hard work that - went into the base documents. - - The following people contributed to portions of this document in some - fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman, - Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam - Weiler. - - - - -Hardaker Standards Track [Page 5] - -RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 - - -8. References - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC - 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security - Extensions", RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [SHA256] National Institute of Standards and Technology, "Secure - Hash Algorithm. NIST FIPS 180-2", August 2002. - -8.2. Informative References - - [SHA256CODE] Eastlake, D., "US Secure Hash Algorithms (SHA)", Work in - Progress. - -Author's Address - - Wes Hardaker - Sparta - P.O. Box 382 - Davis, CA 95617 - USA - - EMail: hardaker@tislabs.com - - - - - - - - - - - - - - - -Hardaker Standards Track [Page 6] - -RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Hardaker Standards Track [Page 7] - diff --git a/doc/rfc/rfc4635.txt b/doc/rfc/rfc4635.txt deleted file mode 100644 index 554502dc91e..00000000000 --- a/doc/rfc/rfc4635.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group D. Eastlake 3rd -Request for Comments: 4635 Motorola Laboratories -Category: Standards Track August 2006 - - - HMAC SHA TSIG Algorithm Identifiers - - Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - Use of the Domain Name System TSIG resource record requires - specification of a cryptographic message authentication code. - Currently, identifiers have been specified only for HMAC MD5 (Hashed - Message Authentication Code, Message Digest 5) and GSS (Generic - Security Service) TSIG algorithms. This document standardizes - identifiers and implementation requirements for additional HMAC SHA - (Secure Hash Algorithm) TSIG algorithms and standardizes how to - specify and handle the truncation of HMAC values in TSIG. - -Table of Contents - - 1. Introduction ....................................................2 - 2. Algorithms and Identifiers ......................................2 - 3. Specifying Truncation ...........................................3 - 3.1. Truncation Specification ...................................4 - 4. TSIG Truncation Policy and Error Provisions .....................4 - 5. IANA Considerations .............................................5 - 6. Security Considerations .........................................5 - 7. Normative References ............................................6 - 8. Informative References. .........................................7 - - - - - - - - - - -Eastlake 3rd Standards Track [Page 1] - -RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 - - -1. Introduction - - [RFC2845] specifies a TSIG Resource Record (RR) that can be used to - authenticate DNS (Domain Name System [STD13]) queries and responses. - This RR contains a domain name syntax data item that names the - authentication algorithm used. [RFC2845] defines the - HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC - (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5 - (Message Digest 5) [RFC1321] hash algorithm. IANA has also - registered "gss-tsig" as an identifier for TSIG authentication where - the cryptographic operations are delegated to the Generic Security - Service (GSS) [RFC3645]. - - Note that use of TSIG presumes prior agreement, between the resolver - and server involved, as to the algorithm and key to be used. - - In Section 2, this document specifies additional names for TSIG - authentication algorithms based on US NIST SHA (United States, - National Institute of Science and Technology, Secure Hash Algorithm) - algorithms and HMAC and specifies the implementation requirements for - those algorithms. - - In Section 3, this document specifies the effect of inequality - between the normal output size of the specified hash function and the - length of MAC (Message Authentication Code) data given in the TSIG - RR. In particular, it specifies that a shorter-length field value - specifies truncation and that a longer-length field is an error. - - In Section 4, policy restrictions and implications related to - truncation are described and specified, as is a new error code to - indicate truncation shorter than that permitted by policy. - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in - this document are to be interpreted as described in [RFC2119]. - -2. Algorithms and Identifiers - - TSIG Resource Records (RRs) [RFC2845] are used to authenticate DNS - queries and responses. They are intended to be efficient symmetric - authentication codes based on a shared secret. (Asymmetric - signatures can be provided using the SIG RR [RFC2931]. In - particular, SIG(0) can be used for transaction signatures.) Used - with a strong hash function, HMAC [RFC2104] provides a way to - calculate such symmetric authentication codes. The only specified - HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG- - ALG.REG.INT, based on MD5 [RFC1321]. - - - - - -Eastlake 3rd Standards Track [Page 2] - -RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 - - - The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as - compared with the 128 bits for MD5, and additional hash algorithms in - the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and - 512 bits may be preferred in some cases. This is because - increasingly successful cryptanalytic attacks are being made on the - shorter hashes. - - Use of TSIG between a DNS resolver and server is by mutual agreement. - That agreement can include the support of additional algorithms and - criteria as to which algorithms and truncations are acceptable, - subject to the restriction and guidelines in Sections 3 and 4 below. - Key agreement can be by the TKEY mechanism [RFC2930] or some other - mutually agreeable method. - - The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are - included in the table below for convenience. Implementations that - support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY - implement gss-tsig and the other algorithms listed below. - - Mandatory HMAC-MD5.SIG-ALG.REG.INT - Optional gss-tsig - Mandatory hmac-sha1 - Optional hmac-sha224 - Mandatory hmac-sha256 - Optional hamc-sha384 - Optional hmac-sha512 - - SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented. - -3. Specifying Truncation - - When space is at a premium and the strength of the full length of an - HMAC is not needed, it is reasonable to truncate the HMAC output and - use the truncated value for authentication. HMAC SHA-1 truncated to - 96 bits is an option available in several IETF protocols, including - IPsec and TLS. - - The TSIG RR [RFC2845] includes a "MAC size" field, which gives the - size of the MAC field in octets. However, [RFC2845] does not specify - what to do if this MAC size differs from the length of the output of - HMAC for a particular hash function. Truncation is indicated by a - MAC size less than the HMAC size, as specified below. - - - - - - - - - -Eastlake 3rd Standards Track [Page 3] - -RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 - - -3.1. Truncation Specification - - The specification for TSIG handling is changed as follows: - - 1. If "MAC size" field is greater than HMAC output length: - - This case MUST NOT be generated and, if received, MUST cause - the packet to be dropped and RCODE 1 (FORMERR) to be returned. - - 2. If "MAC size" field equals HMAC output length: - - Operation is as described in [RFC2845], and the entire output - HMAC output is present. - - 3. "MAC size" field is less than HMAC output length but greater than - that specified in case 4, below: - - This is sent when the signer has truncated the HMAC output to - an allowable length, as described in RFC 2104, taking initial - octets and discarding trailing octets. TSIG truncation can only - be to an integral number of octets. On receipt of a packet with - truncation thus indicated, the locally calculated MAC is similarly - truncated and only the truncated values are compared for - authentication. The request MAC used when calculating the TSIG - MAC for a reply is the truncated request MAC. - - 4. "MAC size" field is less than the larger of 10 (octets) and half - the length of the hash function in use: - - With the exception of certain TSIG error messages described in - RFC 2845, Section 3.2, where it is permitted that the MAC size be - zero, this case MUST NOT be generated and, if received, MUST cause - the packet to be dropped and RCODE 1 (FORMERR) to be returned. - The size limit for this case can also, for the hash functions - mentioned in this document, be stated as less than half the hash - function length for hash functions other than MD5 and less than 10 - octets for MD5. - -4. TSIG Truncation Policy and Error Provisions - - Use of TSIG is by mutual agreement between a resolver and server. - Implicit in such "agreement" are criterion as to acceptable keys and - algorithms and, with the extensions in this document, truncations. - Note that it is common for implementations to bind the TSIG secret - key or keys that may be in place at a resolver and server to - particular algorithms. Thus, such implementations only permit the - - - - - -Eastlake 3rd Standards Track [Page 4] - -RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 - - - use of an algorithm if there is an associated key in place. Receipt - of an unknown, unimplemented, or disabled algorithm typically results - in a BADKEY error. - - Local policies MAY require the rejection of TSIGs, even though - they use an algorithm for which implementation is mandatory. - - When a local policy permits acceptance of a TSIG with a particular - algorithm and a particular non-zero amount of truncation, it SHOULD - also permit the use of that algorithm with lesser truncation (a - longer MAC) up to the full HMAC output. - - Regardless of a lower acceptable truncated MAC length specified by - local policy, a reply SHOULD be sent with a MAC at least as long as - that in the corresponding request, unless the request specified a MAC - length longer than the HMAC output. - - Implementations permitting multiple acceptable algorithms and/or - truncations SHOULD permit this list to be ordered by presumed - strength and SHOULD allow different truncations for the same - algorithm to be treated as separate entities in this list. When so - implemented, policies SHOULD accept a presumed stronger algorithm and - truncation than the minimum strength required by the policy. - - If a TSIG is received with truncation that is permitted under - Section 3 above but the MAC is too short for the local policy in - force, an RCODE of 22 (BADTRUNC) MUST be returned. - -5. IANA Considerations - - This document (1) registers the new TSIG algorithm identifiers listed - in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in - Section 4 [RFC2845]. - -6. Security Considerations - - For all of the message authentication code algorithms listed herein, - those producing longer values are believed to be stronger; however, - while there have been some arguments that mild truncation can - strengthen a MAC by reducing the information available to an - attacker, excessive truncation clearly weakens authentication by - reducing the number of bits an attacker has to try to break the - authentication by brute force [RFC2104]. - - Significant progress has been made recently in cryptanalysis of hash - function of the types used herein, all of which ultimately derive - from the design of MD4. While the results so far should not effect - - - - -Eastlake 3rd Standards Track [Page 5] - -RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 - - - HMAC, the stronger SHA-1 and SHA-256 algorithms are being made - mandatory due to caution. - - See the Security Considerations section of [RFC2845]. See also the - Security Considerations section of [RFC2104] from which the limits on - truncation in this RFC were taken. - -7. Normative References - - [FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US - Federal Information Processing Standard, with Change - Notice 1, February 2004. - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC - 1321, April 1992. - - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: - Keyed-Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for - DNS (TSIG)", RFC 2845, May 2000. - - [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm - 1 (SHA1)", RFC 3174, September 2001. - - [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", - RFC 3874, September 2004. - - [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms - (SHA)", RFC 4634, July 2006. - - [STD13] Mockapetris, P., "Domain names - concepts and - facilities", STD 13, RFC 1034, November 1987. - - Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - - - - - - - - - -Eastlake 3rd Standards Track [Page 6] - -RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 - - -8. Informative References. - - [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures - ( SIG(0)s )", RFC 2931, September 2000. - - [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., - and R. Hall, "Generic Security Service Algorithm for - Secret Key Transaction Authentication for DNS (GSS- - TSIG)", RFC 3645, October 2003. - -Author's Address - - Donald E. Eastlake 3rd - Motorola Laboratories - 155 Beaver Street - Milford, MA 01757 USA - - Phone: +1-508-786-7554 (w) - EMail: Donald.Eastlake@motorola.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake 3rd Standards Track [Page 7] - -RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Eastlake 3rd Standards Track [Page 8] - diff --git a/doc/rfc/rfc4892.txt b/doc/rfc/rfc4892.txt deleted file mode 100644 index a89d3fb0892..00000000000 --- a/doc/rfc/rfc4892.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -Network Working Group S. Woolf -Request for Comments: 4892 Internet Systems Consortium, Inc. -Category: Informational D. Conrad - ICANN - June 2007 - - - Requirements for a Mechanism Identifying a Name Server Instance - -Status of This Memo - - This memo provides information for the Internet community. It does - not specify an Internet standard of any kind. Distribution of this - memo is unlimited. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - With the increased use of DNS anycast, load balancing, and other - mechanisms allowing more than one DNS name server to share a single - IP address, it is sometimes difficult to tell which of a pool of name - servers has answered a particular query. A standardized mechanism to - determine the identity of a name server responding to a particular - query would be useful, particularly as a diagnostic aid for - administrators. Existing ad hoc mechanisms for addressing this need - have some shortcomings, not the least of which is the lack of prior - analysis of exactly how such a mechanism should be designed and - deployed. This document describes the existing convention used in - some widely deployed implementations of the DNS protocol, including - advantages and disadvantages, and discusses some attributes of an - improved mechanism. - -1. Introduction and Rationale - - Identifying which name server is responding to queries is often - useful, particularly in attempting to diagnose name server - difficulties. This is most obviously useful for authoritative - nameservers in the attempt to diagnose the source or prevalence of - inaccurate data, but can also conceivably be useful for caching - resolvers in similar and other situations. Furthermore, the ability - to identify which server is responding to a query has become more - useful as DNS has become more critical to more Internet users, and as - network and server deployment topologies have become more complex. - - - - - -Woolf & Conrad Informational [Page 1] - -RFC 4892 Serverid June 2007 - - - The conventional means for determining which of several possible - servers is answering a query has traditionally been based on the use - of the server's IP address as a unique identifier. However, the - modern Internet has seen the deployment of various load balancing, - fault-tolerance, or attack-resistance schemes such as shared use of - unicast IP addresses as documented in [RFC3258]. An unfortunate side - effect of these schemes has been to make the use of IP addresses as - identifiers associated with DNS (or any other) service somewhat - problematic. Specifically, multiple dedicated DNS queries may not go - to the same server even though sent to the same IP address. Non-DNS - methods such as ICMP ping, TCP connections, or non-DNS UDP packets - (such as those generated by tools like "traceroute"), etc., may well - be even less certain to reach the same server as the one which - receives the DNS queries. - - There is a well-known and frequently-used technique for determining - an identity for a nameserver more specific than the possibly-non- - unique "server that answered the query I sent to IP address A.B.C.D". - The widespread use of the existing convention suggests a need for a - documented, interoperable means of querying the identity of a - nameserver that may be part of an anycast or load-balancing cluster. - At the same time, however, it also has some drawbacks that argue - against standardizing it as it's been practiced so far. - -2. Existing Conventions - - For some time, the commonly deployed Berkeley Internet Name Domain - (BIND) implementation of the DNS protocol suite from the Internet - Systems Consortium [BIND] has supported a way of identifying a - particular server via the use of a standards-compliant, if somewhat - unusual, DNS query. Specifically, a query to a recent BIND server - for a TXT resource record in class 3 (CHAOS) for the domain name - "HOSTNAME.BIND." will return a string that can be configured by the - name server administrator to provide a unique identifier for the - responding server. (The value defaults to the result of a - gethostname() call). This mechanism, which is an extension of the - BIND convention of using CHAOS class TXT RR queries to sub-domains of - the "BIND." domain for version information, has been copied by - several name server vendors. - - A refinement to the BIND-based mechanism, which dropped the - implementation-specific label, replaces "BIND." with "SERVER.". Thus - the query label to learn the unique name of a server may appear as - "ID.SERVER.". - - (For reference, the other well-known name used by recent versions of - BIND within the CHAOS class "BIND." domain is "VERSION.BIND.". A - query for a CHAOS TXT RR for this name will return an - - - -Woolf & Conrad Informational [Page 2] - -RFC 4892 Serverid June 2007 - - - administratively defined string which defaults to the software - version of the server responding. This is, however, not generally - implemented by other vendors.) - -2.1. Advantages - - There are several valuable attributes to this mechanism, which - account for its usefulness. - - 1. The "HOSTNAME.BIND." or "ID.SERVER." query response mechanism is - within the DNS protocol itself. An identification mechanism that - relies on the DNS protocol is more likely to be successful - (although not guaranteed) in going to the same system as a - "normal" DNS query. - - 2. Since the identity information is requested and returned within - the DNS protocol, it doesn't require allowing any other query - mechanism to the server, such as holes in firewalls for - otherwise-unallowed ICMP Echo requests. Thus it is likely to - reach the same server over a path subject to the same routing, - resource, and security policy as the query, without any special - exceptions to site security policy. - - 3. It is simple to configure. An administrator can easily turn on - this feature and control the results of the relevant query. - - 4. It allows the administrator complete control of what information - is given out in the response, minimizing passive leakage of - implementation or configuration details. Such details are often - considered sensitive by infrastructure operators. - -2.2. Disadvantages - - At the same time, there are some serious drawbacks to the CHAOS/TXT - query mechanism that argue against standardizing it as it currently - operates. - - 1. It requires an additional query to correlate between the answer - to a DNS query under normal conditions and the supposed identity - of the server receiving the query. There are a number of - situations in which this simply isn't reliable. - - 2. It reserves an entire class in the DNS (CHAOS) for what amounts - to one zone. While CHAOS class is defined in [RFC1034] and - [RFC1035], it's not clear that supporting it solely for this - purpose is a good use of the namespace or of implementation - effort. - - - - -Woolf & Conrad Informational [Page 3] - -RFC 4892 Serverid June 2007 - - - 3. The initial and still common form, using "BIND.", is - implementation specific. BIND is one DNS implementation. At the - time of this writing, it is probably most prevalent for - authoritative servers. This does not justify standardizing on - its ad hoc solution to a problem shared across many operators and - implementors. Meanwhile, the aforementioned refinement changes - the query label but preserves the ad hoc CHAOS/TXT mechanism. - - 4. There is no convention or shared understanding of what - information an answer to such a query for a server identity could - or should contain, including a possible encoding or - authentication mechanism. - - 5. Hypothetically, since DNSSEC has been defined to cover all DNS - classes, the TXT RRs returned in response to the "ID.SERVER." - query could be signed, which has the advantages described in - [RFC4033]. However, since DNSSEC deployment for the CHAOS class - is neither existent nor foreseeable, and since the "ID.SERVER." - TXT RR is expected to be unique per server, this would be - impossible in practice. - - The first of the listed disadvantages may be technically the most - serious. It argues for an attempt to design a good answer to the - problem, "I need to know what nameserver is answering my queries", - not simply a convenient one. - -3. Characteristics of an Implementation Neutral Convention - - The discussion above of advantages and disadvantages to the - "HOSTNAME.BIND." mechanism suggest some requirements for a better - solution to the server identification problem. These are summarized - here as guidelines for any effort to provide appropriate protocol - extensions: - - 1. The mechanism adopted must be in-band for the DNS protocol. That - is, it needs to allow the query for the server's identifying - information to be part of a normal, operational query. It should - also permit a separate, dedicated query for the server's - identifying information. But it should preserve the ability of - the CHAOS/TXT query-based mechanism to work through firewalls and - in other situations where only DNS can be relied upon to reach - the server of interest. - - 2. The new mechanism should not require dedicated namespaces or - other reserved values outside of the existing protocol mechanisms - for these, i.e., the OPT pseudo-RR. In particular, it should not - propagate the existing drawback of requiring support for a CLASS - - - - -Woolf & Conrad Informational [Page 4] - -RFC 4892 Serverid June 2007 - - - and top level domain in the authoritative server (or the querying - tool) to be useful. - - 3. Support for the identification functionality should be easy to - implement and easy to enable. It must be easy to disable and - should lend itself to access controls on who can query for it. - - 4. It should be possible to return a unique identifier for a server - without requiring the exposure of information that may be non- - public and considered sensitive by the operator, such as a - hostname or unicast IP address maintained for administrative - purposes. - - 5. It should be possible to authenticate the received data by some - mechanism analogous to those provided by DNSSEC. In this - context, the need could be met by including encryption options in - the specification of a new mechanism. - - 6. The identification mechanism should not be implementation- - specific. - -4. IANA Considerations - - This document proposes no specific IANA action. Protocol extensions, - if any, to meet the requirements described are out of scope for this - document. A proposed extension, specified and adopted by normal IETF - process, is described in [NSID], including relevant IANA action. - -5. Security Considerations - - Providing identifying information as to which server is responding to - a particular query from a particular location in the Internet can be - seen as information leakage and thus a security risk. This motivates - the suggestion above that a new mechanism for server identification - allow the administrator to disable the functionality altogether or - partially restrict availability of the data. It also suggests that - the server identification data should not be readily correlated with - a hostname or unicast IP address that may be considered private to - the nameserver operator's management infrastructure. - - Propagation of protocol or service meta-data can sometimes expose the - application to denial of service or other attack. As the DNS is a - critically important infrastructure service for the production - Internet, extra care needs to be taken against this risk for - designers, implementors, and operators of a new mechanism for server - identification. - - - - - -Woolf & Conrad Informational [Page 5] - -RFC 4892 Serverid June 2007 - - - Both authentication and confidentiality of server identification data - are potentially of interest to administrators -- that is, operators - may wish to make such data available and reliable to themselves and - their chosen associates only. This constraint would imply both an - ability to authenticate it to themselves and to keep it private from - arbitrary other parties, which leads to characteristics 4 and 5 of an - improved solution. - -6. Acknowledgements - - The technique for host identification documented here was initially - implemented by Paul Vixie of the Internet Software Consortium in the - Berkeley Internet Name Daemon package. Comments and questions on - earlier versions were provided by Bob Halley, Brian Wellington, - Andreas Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and - members of the ICANN Root Server System Advisory Committee. The - newest version takes a significantly different direction from - previous versions, owing to discussion among contributors to the - DNSOP working group and others, particularly Olafur Gudmundsson, Ed - Lewis, Bill Manning, Sam Weiler, and Rob Austein. - -7. References - -7.1. Normative References - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification", STD 13, RFC 1035, November 1987. - - [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via - Shared Unicast Addresses", RFC 3258, April 2002. - -7.2. Informative References - - [BIND] ISC, "BIND 9 Configuration Reference". - - [NSID] Austein, R., "DNS Name Server Identifier Option (NSID)", - Work in Progress, June 2006. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC - 4033, March 2005. - - - - - - - -Woolf & Conrad Informational [Page 6] - -RFC 4892 Serverid June 2007 - - -Authors' Addresses - - Suzanne Woolf - Internet Systems Consortium, Inc. - 950 Charter Street - Redwood City, CA 94063 - US - - Phone: +1 650 423-1333 - EMail: woolf@isc.org - URI: http://www.isc.org/ - - - David Conrad - ICANN - 4676 Admiralty Way - Marina del Rey, CA 90292 - US - - Phone: +1 310 823 9358 - EMail: david.conrad@icann.org - URI: http://www.iana.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Woolf & Conrad Informational [Page 7] - -RFC 4892 Serverid June 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - -Woolf & Conrad Informational [Page 8] - diff --git a/doc/rfc/rfc5011.txt b/doc/rfc/rfc5011.txt deleted file mode 100644 index 42235e977f8..00000000000 --- a/doc/rfc/rfc5011.txt +++ /dev/null @@ -1,787 +0,0 @@ - - - - - - -Network Working Group M. StJohns -Request for Comments: 5011 Independent -Category: Standards Track September 2007 - - - Automated Updates of DNS Security (DNSSEC) Trust Anchors - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Abstract - - This document describes a means for automated, authenticated, and - authorized updating of DNSSEC "trust anchors". The method provides - protection against N-1 key compromises of N keys in the trust point - key set. Based on the trust established by the presence of a current - anchor, other anchors may be added at the same place in the - hierarchy, and, ultimately, supplant the existing anchor(s). - - This mechanism will require changes to resolver management behavior - (but not resolver resolution behavior), and the addition of a single - flag bit to the DNSKEY record. - - - - - - - - - - - - - - - - - - - - - - - - -StJohns Standards Track [Page 1] - -RFC 5011 Trust Anchor Update September 2007 - - -Table of Contents - - 1. Introduction ....................................................2 - 1.1. Compliance Nomenclature ....................................3 - 2. Theory of Operation .............................................3 - 2.1. Revocation .................................................4 - 2.2. Add Hold-Down ..............................................4 - 2.3. Active Refresh .............................................5 - 2.4. Resolver Parameters ........................................6 - 2.4.1. Add Hold-Down Time ..................................6 - 2.4.2. Remove Hold-Down Time ...............................6 - 2.4.3. Minimum Trust Anchors per Trust Point ...............6 - 3. Changes to DNSKEY RDATA Wire Format .............................6 - 4. State Table .....................................................6 - 4.1. Events .....................................................7 - 4.2. States .....................................................7 - 5. Trust Point Deletion ............................................8 - 6. Scenarios - Informative .........................................9 - 6.1. Adding a Trust Anchor ......................................9 - 6.2. Deleting a Trust Anchor ....................................9 - 6.3. Key Roll-Over .............................................10 - 6.4. Active Key Compromised ....................................10 - 6.5. Stand-by Key Compromised ..................................10 - 6.6. Trust Point Deletion ......................................10 - 7. IANA Considerations ............................................11 - 8. Security Considerations ........................................11 - 8.1. Key Ownership vs. Acceptance Policy .......................11 - 8.2. Multiple Key Compromise ...................................12 - 8.3. Dynamic Updates ...........................................12 - 9. Normative References ...........................................12 - 10. Informative References ........................................12 - -1. Introduction - - As part of the reality of fielding DNSSEC (Domain Name System - Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has - come to the realization that there will not be one signed name space, - but rather islands of signed name spaces each originating from - specific points (i.e., 'trust points') in the DNS tree. Each of - those islands will be identified by the trust point name, and - validated by at least one associated public key. For the purpose of - this document, we'll call the association of that name and a - particular key a 'trust anchor'. A particular trust point can have - more than one key designated as a trust anchor. - - For a DNSSEC-aware resolver to validate information in a DNSSEC - protected branch of the hierarchy, it must have knowledge of a trust - anchor applicable to that branch. It may also have more than one - - - -StJohns Standards Track [Page 2] - -RFC 5011 Trust Anchor Update September 2007 - - - trust anchor for any given trust point. Under current rules, a chain - of trust for DNSSEC-protected data that chains its way back to ANY - known trust anchor is considered 'secure'. - - Because of the probable balkanization of the DNSSEC tree due to - signing voids at key locations, a resolver may need to know literally - thousands of trust anchors to perform its duties (e.g., consider an - unsigned ".COM"). Requiring the owner of the resolver to manually - manage these many relationships is problematic. It's even more - problematic when considering the eventual requirement for key - replacement/update for a given trust anchor. The mechanism described - herein won't help with the initial configuration of the trust anchors - in the resolvers, but should make trust point key - replacement/rollover more viable. - - As mentioned above, this document describes a mechanism whereby a - resolver can update the trust anchors for a given trust point, mainly - without human intervention at the resolver. There are some corner - cases discussed (e.g., multiple key compromise) that may require - manual intervention, but they should be few and far between. This - document DOES NOT discuss the general problem of the initial - configuration of trust anchors for the resolver. - -1.1. Compliance Nomenclature - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in BCP 14, [RFC2119]. - -2. Theory of Operation - - The general concept of this mechanism is that existing trust anchors - can be used to authenticate new trust anchors at the same point in - the DNS hierarchy. When a zone operator adds a new SEP key (i.e., a - DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section - 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is - validated by an existing trust anchor, then the resolver can add the - new key to its set of valid trust anchors for that trust point. - - There are some issues with this approach that need to be mitigated. - For example, a compromise of one of the existing keys could allow an - attacker to add their own 'valid' data. This implies a need for a - method to revoke an existing key regardless of whether or not that - key is compromised. As another example, assuming a single key - compromise, we need to prevent an attacker from adding a new key and - revoking all the other old keys. - - - - - -StJohns Standards Track [Page 3] - -RFC 5011 Trust Anchor Update September 2007 - - -2.1. Revocation - - Assume two trust anchor keys A and B. Assume that B has been - compromised. Without a specific revocation bit, B could invalidate A - simply by sending out a signed trust point key set that didn't - contain A. To fix this, we add a mechanism that requires knowledge - of the private key of a DNSKEY to revoke that DNSKEY. - - A key is considered revoked when the resolver sees the key in a - self-signed RRSet and the key has the REVOKE bit (see Section 7 - below) set to '1'. Once the resolver sees the REVOKE bit, it MUST - NOT use this key as a trust anchor or for any other purpose except to - validate the RRSIG it signed over the DNSKEY RRSet specifically for - the purpose of validating the revocation. Unlike the 'Add' operation - below, revocation is immediate and permanent upon receipt of a valid - revocation at the resolver. - - A self-signed RRSet is a DNSKEY RRSet that contains the specific - DNSKEY and for which there is a corresponding validated RRSIG record. - It's not a special DNSKEY RRSet, just a way of describing the - validation requirements for that RRSet. - - N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint - than one without the bit set. This affects the matching of a DNSKEY - to DS records in the parent [RFC3755], or the fingerprint stored at a - resolver used to configure a trust point. - - In the given example, the attacker could revoke B because it has - knowledge of B's private key, but could not revoke A. - -2.2. Add Hold-Down - - Assume two trust point keys A and B. Assume that B has been - compromised. An attacker could generate and add a new trust anchor - key C (by adding C to the DNSKEY RRSet and signing it with B), and - then invalidate the compromised key. This would result in both the - attacker and owner being able to sign data in the zone and have it - accepted as valid by resolvers. - - To mitigate but not completely solve this problem, we add a hold-down - time to the addition of the trust anchor. When the resolver sees a - new SEP key in a validated trust point DNSKEY RRSet, the resolver - starts an acceptance timer, and remembers all the keys that validated - the RRSet. If the resolver ever sees the DNSKEY RRSet without the - new key but validly signed, it stops the acceptance process for that - key and resets the acceptance timer. If all of the keys that were - - - - - -StJohns Standards Track [Page 4] - -RFC 5011 Trust Anchor Update September 2007 - - - originally used to validate this key are revoked prior to the timer - expiring, the resolver stops the acceptance process and resets the - timer. - - Once the timer expires, the new key will be added as a trust anchor - the next time the validated RRSet with the new key is seen at the - resolver. The resolver MUST NOT treat the new key as a trust anchor - until the hold-down time expires AND it has retrieved and validated a - DNSKEY RRSet after the hold-down time that contains the new key. - - N.B.: Once the resolver has accepted a key as a trust anchor, the key - MUST be considered a valid trust anchor by that resolver until - explicitly revoked as described above. - - In the given example, the zone owner can recover from a compromise by - revoking B and adding a new key D and signing the DNSKEY RRSet with - both A and B. - - The reason this does not completely solve the problem has to do with - the distributed nature of DNS. The resolver only knows what it sees. - A determined attacker who holds one compromised key could keep a - single resolver from realizing that the key had been compromised by - intercepting 'real' data from the originating zone and substituting - their own (e.g., using the example, signed only by B). This is no - worse than the current situation assuming a compromised key. - -2.3. Active Refresh - - A resolver that has been configured for an automatic update of keys - from a particular trust point MUST query that trust point (e.g., do a - lookup for the DNSKEY RRSet and related RRSIG records) no less often - than the lesser of 15 days, half the original TTL for the DNSKEY - RRSet, or half the RRSIG expiration interval and no more often than - once per hour. The expiration interval is the amount of time from - when the RRSIG was last retrieved until the expiration time in the - RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL, - 1/2*RRSigExpirationInterval)) - - If the query fails, the resolver MUST repeat the query until - satisfied no more often than once an hour and no less often than the - lesser of 1 day, 10% of the original TTL, or 10% of the original - expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day, - .1 * origTTL, .1 * expireInterval)). - - - - - - - - -StJohns Standards Track [Page 5] - -RFC 5011 Trust Anchor Update September 2007 - - -2.4. Resolver Parameters - -2.4.1. Add Hold-Down Time - - The add hold-down time is 30 days or the expiration time of the - original TTL of the first trust point DNSKEY RRSet that contained the - new key, whichever is greater. This ensures that at least two - validated DNSKEY RRSets that contain the new key MUST be seen by the - resolver prior to the key's acceptance. - -2.4.2. Remove Hold-Down Time - - The remove hold-down time is 30 days. This parameter is solely a key - management database bookeeping parameter. Failure to remove - information about the state of defunct keys from the database will - not adversely impact the security of this protocol, but may end up - with a database cluttered with obsolete key information. - -2.4.3. Minimum Trust Anchors per Trust Point - - A compliant resolver MUST be able to manage at least five SEP keys - per trust point. - -3. Changes to DNSKEY RDATA Wire Format - - Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag. - If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY) - signed by the associated key, then the resolver MUST consider this - key permanently invalid for all purposes except for validating the - revocation. - -4. State Table - - The most important thing to understand is the resolver's view of any - key at a trust point. The following state table describes this view - at various points in the key's lifetime. The table is a normative - part of this specification. The initial state of the key is 'Start'. - The resolver's view of the state of the key changes as various events - occur. - - This is the state of a trust-point key as seen from the resolver. - The column on the left indicates the current state. The header at - the top shows the next state. The intersection of the two shows the - event that will cause the state to transition from the current state - to the next. - - - - - - -StJohns Standards Track [Page 6] - -RFC 5011 Trust Anchor Update September 2007 - - - NEXT STATE - -------------------------------------------------- - FROM |Start |AddPend |Valid |Missing|Revoked|Removed| - ---------------------------------------------------------- - Start | |NewKey | | | | | - ---------------------------------------------------------- - AddPend |KeyRem | |AddTime| | | | - ---------------------------------------------------------- - Valid | | | |KeyRem |Revbit | | - ---------------------------------------------------------- - Missing | | |KeyPres| |Revbit | | - ---------------------------------------------------------- - Revoked | | | | | |RemTime| - ---------------------------------------------------------- - Removed | | | | | | | - ---------------------------------------------------------- - - State Table - -4.1. Events - - NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key. - That key will become a new trust anchor for the named trust - point after it's been present in the RRSet for at least 'add - time'. - - KeyPres The key has returned to the valid DNSKEY RRSet. - - KeyRem The resolver sees a valid DNSKEY RRSet that does not contain - this key. - - AddTime The key has been in every valid DNSKEY RRSet seen for at - least the 'add time'. - - RemTime A revoked key has been missing from the trust-point DNSKEY - RRSet for sufficient time to be removed from the trust set. - - RevBit The key has appeared in the trust anchor DNSKEY RRSet with - its "REVOKED" bit set, and there is an RRSig over the DNSKEY - RRSet signed by this key. - -4.2. States - - Start The key doesn't yet exist as a trust anchor at the resolver. - It may or may not exist at the zone server, but either - hasn't yet been seen at the resolver or was seen but was - absent from the last DNSKEY RRSet (e.g., KeyRem event). - - - - -StJohns Standards Track [Page 7] - -RFC 5011 Trust Anchor Update September 2007 - - - AddPend The key has been seen at the resolver, has its 'SEP' bit - set, and has been included in a validated DNSKEY RRSet. - There is a hold-down time for the key before it can be used - as a trust anchor. - - Valid The key has been seen at the resolver and has been included - in all validated DNSKEY RRSets from the time it was first - seen through the hold-down time. It is now valid for - verifying RRSets that arrive after the hold-down time. - Clarification: The DNSKEY RRSet does not need to be - continuously present at the resolver (e.g., its TTL might - expire). If the RRSet is seen and is validated (i.e., - verifies against an existing trust anchor), this key MUST be - in the RRSet, otherwise a 'KeyRem' event is triggered. - - Missing This is an abnormal state. The key remains a valid trust- - point key, but was not seen at the resolver in the last - validated DNSKEY RRSet. This is an abnormal state because - the zone operator should be using the REVOKE bit prior to - removal. - - Revoked This is the state a key moves to once the resolver sees an - RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet - contains this key with its REVOKE bit set to '1'. Once in - this state, this key MUST permanently be considered invalid - as a trust anchor. - - Removed After a fairly long hold-down time, information about this - key may be purged from the resolver. A key in the removed - state MUST NOT be considered a valid trust anchor. (Note: - this state is more or less equivalent to the "Start" state, - except that it's bad practice to re-introduce previously - used keys -- think of this as the holding state for all the - old keys for which the resolver no longer needs to track - state.) - -5. Trust Point Deletion - - A trust point that has all of its trust anchors revoked is considered - deleted and is treated as if the trust point was never configured. - If there are no superior configured trust points, data at and below - the deleted trust point are considered insecure by the resolver. If - there ARE superior configured trust points, data at and below the - deleted trust point are evaluated with respect to the superior trust - point(s). - - Alternately, a trust point that is subordinate to another configured - trust point MAY be deleted by a resolver after 180 days, where such a - - - -StJohns Standards Track [Page 8] - -RFC 5011 Trust Anchor Update September 2007 - - - subordinate trust point validly chains to a superior trust point. - The decision to delete the subordinate trust anchor is a local - configuration decision. Once the subordinate trust point is deleted, - validation of the subordinate zone is dependent on validating the - chain of trust to the superior trust point. - -6. Scenarios - Informative - - The suggested model for operation is to have one active key and one - stand-by key at each trust point. The active key will be used to - sign the DNSKEY RRSet. The stand-by key will not normally sign this - RRSet, but the resolver will accept it as a trust anchor if/when it - sees the signature on the trust point DNSKEY RRSet. - - Since the stand-by key is not in active signing use, the associated - private key may (and should) be provided with additional protections - not normally available to a key that must be used frequently (e.g., - locked in a safe, split among many parties, etc). Notionally, the - stand-by key should be less subject to compromise than an active key, - but that will be dependent on operational concerns not addressed - here. - -6.1. Adding a Trust Anchor - - Assume an existing trust anchor key 'A'. - - 1. Generate a new key pair. - - 2. Create a DNSKEY record from the key pair and set the SEP and Zone - Key bits. - - 3. Add the DNSKEY to the RRSet. - - 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key - - 'A'. - - 5. Wait for various resolvers' timers to go off and for them to - retrieve the new DNSKEY RRSet and signatures. - - 6. The new trust anchor will be populated at the resolvers on the - schedule described by the state table and update algorithm -- see - Sections 2 and 4 above. - -6.2. Deleting a Trust Anchor - - Assume existing trust anchors 'A' and 'B' and that you want to revoke - and delete 'A'. - - - - -StJohns Standards Track [Page 9] - -RFC 5011 Trust Anchor Update September 2007 - - - 1. Set the revocation bit on key 'A'. - - 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked. - The operator should include the revoked 'A' in the RRSet for at - least the remove hold-down time, but then may remove it from the - DNSKEY RRSet. - -6.3. Key Roll-Over - - Assume existing keys A and B. 'A' is actively in use (i.e. has been - signing the DNSKEY RRSet). 'B' was the stand-by key. (i.e. has been - in the DNSKEY RRSet and is a valid trust anchor, but wasn't being - used to sign the RRSet). - - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'A'. - 4. Sign the RRSet with 'A' and 'B'. - - 'A' is now revoked, 'B' is now the active key, and 'C' will be the - stand-by key once the hold-down expires. The operator should include - the revoked 'A' in the RRSet for at least the remove hold-down time, - but may then remove it from the DNSKEY RRSet. - -6.4. Active Key Compromised - - This is the same as the mechanism for Key Roll-Over (Section 6.3) - above, assuming 'A' is the active key. - -6.5. Stand-by Key Compromised - - Using the same assumptions and naming conventions as Key Roll-Over - (Section 6.3) above: - - 1. Generate a new key pair 'C'. - 2. Add 'C' to the DNSKEY RRSet. - 3. Set the revocation bit on key 'B'. - 4. Sign the RRSet with 'A' and 'B'. - - 'B' is now revoked, 'A' remains the active key, and 'C' will be the - stand-by key once the hold-down expires. 'B' should continue to be - included in the RRSet for the remove hold-down time. - -6.6. Trust Point Deletion - - To delete a trust point that is subordinate to another configured - trust point (e.g., example.com to .com) requires some juggling of the - data. The specific process is: - - - -StJohns Standards Track [Page 10] - -RFC 5011 Trust Anchor Update September 2007 - - - 1. Generate a new DNSKEY and DS record and provide the DS record to - the parent along with DS records for the old keys. - - 2. Once the parent has published the DSs, add the new DNSKEY to the - RRSet and revoke ALL of the old keys at the same time, while - signing the DNSKEY RRSet with all of the old and new keys. - - 3. After 30 days, stop publishing the old, revoked keys and remove - any corresponding DS records in the parent. - - Revoking the old trust-point keys at the same time as adding new keys - that chain to a superior trust prevents the resolver from adding the - new keys as trust anchors. Adding DS records for the old keys avoids - a race condition where either the subordinate zone becomes unsecure - (because the trust point was deleted) or becomes bogus (because it - didn't chain to the superior zone). - -7. IANA Considerations - - The IANA has assigned a bit in the DNSKEY flags field (see Section 7 - of [RFC4034]) for the REVOKE bit (8). - -8. Security Considerations - - In addition to the following sections, see also Theory of Operation - above (Section 2) and especially Section 2.2 for related discussions. - - Security considerations for trust anchor rollover not specific to - this protocol are discussed in [RFC4986]. - -8.1. Key Ownership vs. Acceptance Policy - - The reader should note that, while the zone owner is responsible for - creating and distributing keys, it's wholly the decision of the - resolver owner as to whether to accept such keys for the - authentication of the zone information. This implies the decision to - update trust-anchor keys based on trusting a current trust-anchor key - is also the resolver owner's decision. - - The resolver owner (and resolver implementers) MAY choose to permit - or prevent key status updates based on this mechanism for specific - trust points. If they choose to prevent the automated updates, they - will need to establish a mechanism for manual or other out-of-band - updates, which are outside the scope of this document. - - - - - - - -StJohns Standards Track [Page 11] - -RFC 5011 Trust Anchor Update September 2007 - - -8.2. Multiple Key Compromise - - This scheme permits recovery as long as at least one valid trust- - anchor key remains uncompromised, e.g., if there are three keys, you - can recover if two of them are compromised. The zone owner should - determine their own level of comfort with respect to the number of - active, valid trust anchors in a zone and should be prepared to - implement recovery procedures once they detect a compromise. A - manual or other out-of-band update of all resolvers will be required - if all trust-anchor keys at a trust point are compromised. - -8.3. Dynamic Updates - - Allowing a resolver to update its trust anchor set based on in-band - key information is potentially less secure than a manual process. - However, given the nature of the DNS, the number of resolvers that - would require update if a trust anchor key were compromised, and the - lack of a standard management framework for DNS, this approach is no - worse than the existing situation. - -9. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation - Signer (DS)", RFC 3755, May 2004. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC - 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -10. Informative References - - [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy, - "Requirements Related to DNS Security (DNSSEC) Trust - Anchor Rollover", RFC 4986, August 2007. - - - - - - -StJohns Standards Track [Page 12] - -RFC 5011 Trust Anchor Update September 2007 - - -Author's Address - - Michael StJohns - Independent - - EMail: mstjohns@comcast.net - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -StJohns Standards Track [Page 13] - -RFC 5011 Trust Anchor Update September 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - - - - - - - - - - -StJohns Standards Track [Page 14] - diff --git a/doc/rfc/rfc5702.txt b/doc/rfc/rfc5702.txt deleted file mode 100644 index 5155cc6440c..00000000000 --- a/doc/rfc/rfc5702.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -Network Working Group J. Jansen -Request for Comments: 5702 NLnet Labs -Category: Standards Track October 2009 - - - Use of SHA-2 Algorithms with RSA in - DNSKEY and RRSIG Resource Records for DNSSEC - -Abstract - - This document describes how to produce RSA/SHA-256 and RSA/SHA-512 - DNSKEY and RRSIG resource records for use in the Domain Name System - Security Extensions (RFC 4033, RFC 4034, and RFC 4035). - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the BSD License. - - - - - - - - - - - - - - - -Jansen Standards Track [Page 1] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -Table of Contents - - 1. Introduction ....................................................2 - 2. DNSKEY Resource Records .........................................3 - 2.1. RSA/SHA-256 DNSKEY Resource Records ........................3 - 2.2. RSA/SHA-512 DNSKEY Resource Records ........................3 - 3. RRSIG Resource Records ..........................................3 - 3.1. RSA/SHA-256 RRSIG Resource Records .........................4 - 3.2. RSA/SHA-512 RRSIG Resource Records .........................4 - 4. Deployment Considerations .......................................5 - 4.1. Key Sizes ..................................................5 - 4.2. Signature Sizes ............................................5 - 5. Implementation Considerations ...................................5 - 5.1. Support for SHA-2 Signatures ...............................5 - 5.2. Support for NSEC3 Denial of Existence ......................5 - 6. Examples ........................................................6 - 6.1. RSA/SHA-256 Key and Signature ..............................6 - 6.2. RSA/SHA-512 Key and Signature ..............................7 - 7. IANA Considerations .............................................8 - 8. Security Considerations .........................................8 - 8.1. SHA-1 versus SHA-2 Considerations for RRSIG - Resource Records ...........................................8 - 8.2. Signature Type Downgrade Attacks ...........................8 - 9. Acknowledgments .................................................9 - 10. References .....................................................9 - 10.1. Normative References ......................................9 - 10.2. Informative References ....................................9 - -1. Introduction - - The Domain Name System (DNS) is the global, hierarchical distributed - database for Internet Naming. The DNS has been extended to use - cryptographic keys and digital signatures for the verification of the - authenticity and integrity of its data. [RFC4033], [RFC4034], and - [RFC4035] describe these DNS Security Extensions, called DNSSEC. - - RFC 4034 describes how to store DNSKEY and RRSIG resource records, - and specifies a list of cryptographic algorithms to use. This - document extends that list with the algorithms RSA/SHA-256 and RSA/ - SHA-512, and specifies how to store DNSKEY data and how to produce - RRSIG resource records with these hash algorithms. - - Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family - of algorithms is assumed in this document. - - - - - - - -Jansen Standards Track [Page 2] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - - To refer to both SHA-256 and SHA-512, this document will use the name - SHA-2. This is done to improve readability. When a part of text is - specific for either SHA-256 or SHA-512, their specific names are - used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be - grouped using the name RSA/SHA-2. - - The term "SHA-2" is not officially defined but is usually used to - refer to the collection of the algorithms SHA-224, SHA-256, SHA-384, - and SHA-512. Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2 - will only refer to SHA-256 and SHA-512 in this document. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2. DNSKEY Resource Records - - The format of the DNSKEY RR can be found in [RFC4034]. [RFC3110] - describes the use of RSA/SHA-1 for DNSSEC signatures. - -2.1. RSA/SHA-256 DNSKEY Resource Records - - RSA public keys for use with RSA/SHA-256 are stored in DNSKEY - resource records (RRs) with the algorithm number 8. - - For interoperability, as in [RFC3110], the key size of RSA/SHA-256 - keys MUST NOT be less than 512 bits and MUST NOT be more than 4096 - bits. - -2.2. RSA/SHA-512 DNSKEY Resource Records - - RSA public keys for use with RSA/SHA-512 are stored in DNSKEY - resource records (RRs) with the algorithm number 10. - - The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and - MUST NOT be more than 4096 bits. - -3. RRSIG Resource Records - - The value of the signature field in the RRSIG RR follows the RSASSA- - PKCS1-v1_5 signature scheme and is calculated as follows. The values - for the RDATA fields that precede the signature data are specified in - [RFC4034]. - - - - - - - - -Jansen Standards Track [Page 3] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - - hash = SHA-XXX(data) - - Here XXX is either 256 or 512, depending on the algorithm used, as - specified in FIPS PUB 180-3; "data" is the wire format data of the - resource record set that is signed, as specified in [RFC4034]. - - signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) - - Here "|" is concatenation; "00", "01", "FF", and "00" are fixed - octets of corresponding hexadecimal value; "e" is the private - exponent of the signing RSA key; and "n" is the public modulus of the - signing key. The FF octet MUST be repeated the exact number of times - so that the total length of the concatenated term in parentheses - equals the length of the modulus of the signer's public key ("n"). - - The "prefix" is intended to make the use of standard cryptographic - libraries easier. These specifications are taken directly from the - specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of - [RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2 - of [RFC3447]). The prefixes for the different algorithms are - specified below. - -3.1. RSA/SHA-256 RRSIG Resource Records - - RSA/SHA-256 signatures are stored in the DNS using RRSIG resource - records (RRs) with algorithm number 8. - - The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as - specified in PKCS #1 v2.1 [RFC3447]: - - hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 - -3.2. RSA/SHA-512 RRSIG Resource Records - - RSA/SHA-512 signatures are stored in the DNS using RRSIG resource - records (RRs) with algorithm number 10. - - The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as - specified in PKCS #1 v2.1 [RFC3447]: - - hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 - - - - - - - - - - -Jansen Standards Track [Page 4] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -4. Deployment Considerations - -4.1. Key Sizes - - Apart from the restrictions in Section 2, this document will not - specify what size of keys to use. That is an operational issue and - depends largely on the environment and intended use. A good starting - point for more information would be NIST SP 800-57 [NIST800-57]. - -4.2. Signature Sizes - - In this family of signing algorithms, the size of signatures is - related to the size of the key and not to the hashing algorithm used - in the signing process. Therefore, RRSIG resource records produced - with RSA/SHA-256 or RSA/SHA-512 will have the same size as those - produced with RSA/SHA-1, if the keys have the same length. - -5. Implementation Considerations - -5.1. Support for SHA-2 Signatures - - DNSSEC-aware implementations SHOULD be able to support RRSIG and - DNSKEY resource records created with the RSA/SHA-2 algorithms as - defined in this document. - -5.2. Support for NSEC3 Denial of Existence - - [RFC5155] defines new algorithm identifiers for existing signing - algorithms, to indicate that zones signed with these algorithm - identifiers can use NSEC3 as well as NSEC records to provide denial - of existence. That mechanism was chosen to protect implementations - predating RFC 5155 from encountering resource records about which - they could not know. This document does not define such algorithm - aliases. - - A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate - negative answers in the form of both NSEC and NSEC3 with hash - algorithm 1, as defined in [RFC5155]. An authoritative server that - does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 - with NSEC denial of existence. - - - - - - - - - - - -Jansen Standards Track [Page 5] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -6. Examples - -6.1. RSA/SHA-256 Key and Signature - - Given a private key with the following values (in Base64): - - Private-key-format: v1.2 - Algorithm: 8 (RSASHA256) - Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm - idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q== - PublicExponent: AQAB - PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/ - HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ== - Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk= - Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE= - Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk= - Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE= - Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q= - - The DNSKEY record for this key would be: - - example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI - my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P - kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b} - - With this key, sign the following RRSet, consisting of 1 A record: - - www.example.net. 3600 IN A 192.0.2.91 - - If the inception date is set at 00:00 hours on January 1st, 2000, and - the expiration date at 00:00 hours on January 1st, 2030, the - following signature should be created: - - www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000 - 20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9 - l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa - cFYK/lPtPiVYP4bwg==);{id = 9033} - - - - - - - - - - - - - - -Jansen Standards Track [Page 6] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -6.2. RSA/SHA-512 Key and Signature - - Given a private key with the following values (in Base64): - - Private-key-format: v1.2 - Algorithm: 10 (RSASHA512) - Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf - Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk - 8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V - jXZlNKdyit99waaE4s= - PublicExponent: AQAB - PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6 - AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj - yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3 - SEIAsrB043XzGrKIVE= - Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x - nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ== - Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK - Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw== - Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM - MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q== - Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J - PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w== - Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q - /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ== - - The DNSKEY record for this key would be: - - example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD - p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD - xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g - pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL - );{id = 3740 (zsk), size = 1024b} - - With this key, sign the following RRSet, consisting of 1 A record: - - www.example.net. 3600 IN A 192.0.2.91 - - If the inception date is set at 00:00 hours on January 1st, 2000, and - the expiration date at 00:00 hours on January 1st, 2030, the - following signature should be created: - - www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000 - 20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t - 6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa - eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL - DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw - =);{id = 3740} - - - -Jansen Standards Track [Page 7] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -7. IANA Considerations - - This document updates the IANA registry "DNS SECURITY ALGORITHM - NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols). The - following entries are added to the registry: - - Zone Trans. - Value Description Mnemonic Signing Sec. References - 8 RSA/SHA-256 RSASHA256 Y * RFC 5702 - 10 RSA/SHA-512 RSASHA512 Y * RFC 5702 - - * There has been no determination of standardization of the use of - this algorithm with Transaction Security. - -8. Security Considerations - -8.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records - - Users of DNSSEC are encouraged to deploy SHA-2 as soon as software - implementations allow for it. SHA-2 is widely believed to be more - resilient to attack than SHA-1, and confidence in SHA-1's strength is - being eroded by recently announced attacks. Regardless of whether or - not the attacks on SHA-1 will affect DNSSEC, it is believed (at the - time of this writing) that SHA-2 is the better choice for use in - DNSSEC records. - - SHA-2 is considered sufficiently strong for the immediate future, but - predictions about future development in cryptography and - cryptanalysis are beyond the scope of this document. - - The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one - used for RSA/SHA-1 signatures. This should ease implementation of - the new hashing algorithms in DNSSEC software. - -8.2. Signature Type Downgrade Attacks - - Since each RRSet MUST be signed with each algorithm present in the - DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a - malicious party cannot filter out the RSA/SHA-2 RRSIG and force the - validator to use the RSA/SHA-1 signature if both are present in the - zone. This should provide resilience against algorithm downgrade - attacks, if the validator supports RSA/SHA-2. - - - - - - - - - -Jansen Standards Track [Page 8] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - -9. Acknowledgments - - This document is a minor extension to [RFC4034]. Also, we try to - follow the documents [RFC3110] and [RFC4509] for consistency. The - authors of and contributors to these documents are gratefully - acknowledged for their hard work. - - The following people provided additional feedback and text: Jaap - Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont, - Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose, - Michael St. Johns, and Wouter Wijngaards. - -10. References - -10.1. Normative References - - [FIPS.180-3.2008] - National Institute of Standards and Technology, "Secure - Hash Standard", FIPS PUB 180-3, October 2008. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain - Name System (DNS)", RFC 3110, May 2001. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - -10.2. Informative References - - [NIST800-57] - Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, - "Recommendations for Key Management", NIST SP 800-57, - March 2007. - - [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography - Standards (PKCS) #1: RSA Cryptography Specifications - Version 2.1", RFC 3447, February 2003. - - - -Jansen Standards Track [Page 9] - -RFC 5702 DNSSEC RSA/SHA-2 October 2009 - - - [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - -Author's Address - - Jelte Jansen - NLnet Labs - Science Park 140 - 1098 XG Amsterdam - NL - - EMail: jelte@NLnetLabs.nl - URI: http://www.nlnetlabs.nl/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Jansen Standards Track [Page 10] - -- 2.47.3