diff --git a/bin/tests/system/dnssec/ns3/rsasha256.example.db.in b/bin/tests/system/dnssec/ns3/rsasha256.example.db.in new file mode 100644 index 0000000000..a25c07339f --- /dev/null +++ b/bin/tests/system/dnssec/ns3/rsasha256.example.db.in @@ -0,0 +1,33 @@ +; 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: rsasha256.example.db.in,v 1.2 2009/10/27 22:25:37 marka Exp $ + +$TTL 300 ; 5 minutes +@ IN SOA mname1. . ( + 2009102722 ; serial + 20 ; refresh (20 seconds) + 20 ; retry (20 seconds) + 1814400 ; expire (3 weeks) + 3600 ; minimum (1 hour) + ) + NS ns +ns A 10.53.0.3 + +a A 10.0.0.1 +b A 10.0.0.2 +d A 10.0.0.4 +z A 10.0.0.26 +a.a.a.a.a.a.a.a.a.a.e A 10.0.0.27 +x CNAME a diff --git a/bin/tests/system/dnssec/ns3/rsasha512.example.db.in b/bin/tests/system/dnssec/ns3/rsasha512.example.db.in new file mode 100644 index 0000000000..16ce88b6a7 --- /dev/null +++ b/bin/tests/system/dnssec/ns3/rsasha512.example.db.in @@ -0,0 +1,33 @@ +; 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: rsasha512.example.db.in,v 1.2 2009/10/27 22:25:37 marka Exp $ + +$TTL 300 ; 5 minutes +@ IN SOA mname1. . ( + 2009102722 ; serial + 20 ; refresh (20 seconds) + 20 ; retry (20 seconds) + 1814400 ; expire (3 weeks) + 3600 ; minimum (1 hour) + ) + NS ns +ns A 10.53.0.3 + +a A 10.0.0.1 +b A 10.0.0.2 +d A 10.0.0.4 +z A 10.0.0.26 +a.a.a.a.a.a.a.a.a.a.e A 10.0.0.27 +x CNAME a diff --git a/doc/draft/draft-ietf-6man-text-addr-representation-01.txt b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt new file mode 100644 index 0000000000..f15b069b5b --- /dev/null +++ b/doc/draft/draft-ietf-6man-text-addr-representation-01.txt @@ -0,0 +1,785 @@ + + + +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 new file mode 100644 index 0000000000..25a6dd4d07 --- /dev/null +++ b/doc/draft/draft-ietf-behave-dns64-01.txt @@ -0,0 +1,1624 @@ + + + +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 new file mode 100644 index 0000000000..41ae72ec2e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dns-tcp-requirements-01.txt @@ -0,0 +1,448 @@ + + + +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 new file mode 100644 index 0000000000..0953e28b47 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-09.txt @@ -0,0 +1,672 @@ + + + +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-rfc3597-bis-00.txt b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt new file mode 100644 index 0000000000..ee35cb91af --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-rfc3597-bis-00.txt @@ -0,0 +1,395 @@ + + + + + + +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/rfc/rfc1912.txt b/doc/rfc/rfc1912.txt new file mode 100644 index 0000000000..8ace7d2674 --- /dev/null +++ b/doc/rfc/rfc1912.txt @@ -0,0 +1,899 @@ + + + + + + +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] +