+++ /dev/null
-/*
- * Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC")
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- * PERFORMANCE OF THIS SOFTWARE.
- */
-
-/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */
-
-controls { /* empty */ };
-
-include "trusted.conf";
-
-options {
- query-source address 10.53.0.1;
- notify-source 10.53.0.1;
- transfer-source 10.53.0.1;
- port 5300;
- pid-file "named.pid";
- listen-on { 10.53.0.1; };
- listen-on-v6 { none; };
- recursion no;
-};
-
-zone "." {
- type master;
- file "root.db.signed";
-};
-
+++ /dev/null
-; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC")
-;
-; Permission to use, copy, modify, and/or distribute this software for any
-; purpose with or without fee is hereby granted, provided that the above
-; copyright notice and this permission notice appear in all copies.
-;
-; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-; PERFORMANCE OF THIS SOFTWARE.
-
-; $Id: example.db.in,v 1.2 2009/11/17 23:55:18 marka Exp $
-
-$TTL 30
-@ IN SOA mname1. . (
- 2009110300 ; serial
- 20 ; refresh (20 seconds)
- 20 ; retry (20 seconds)
- 1814400 ; expire (3 weeks)
- 3600 ; minimum (1 hour)
- )
- NS ns2
- MX 10 mail
-ns2 A 10.53.0.2
-mail A 10.0.0.2
+++ /dev/null
-; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC")
-;
-; Permission to use, copy, modify, and/or distribute this software for any
-; purpose with or without fee is hereby granted, provided that the above
-; copyright notice and this permission notice appear in all copies.
-;
-; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-; PERFORMANCE OF THIS SOFTWARE.
-
-; $Id: hostile.db,v 1.2 2009/11/17 23:55:18 marka Exp $
-
-$TTL 30
-@ IN SOA mname1. . (
- 2009110500 ; serial
- 20 ; refresh (20 seconds)
- 20 ; retry (20 seconds)
- 1814400 ; expire (3 weeks)
- 3600 ; minimum (1 hour)
- )
- NS ns3
- MX 10 mail.example.
-ns3 A 10.53.0.3
+++ /dev/null
-; Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC")
-;
-; Permission to use, copy, modify, and/or distribute this software for any
-; purpose with or without fee is hereby granted, provided that the above
-; copyright notice and this permission notice appear in all copies.
-;
-; THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-; REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-; AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-; INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-; LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-; OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-; PERFORMANCE OF THIS SOFTWARE.
-
-; $Id: mail.example.db,v 1.2 2009/11/17 23:55:18 marka Exp $
-
-$TTL 30
-@ IN SOA mname1. . (
- 2009110300 ; serial
- 20 ; refresh (20 seconds)
- 20 ; retry (20 seconds)
- 1814400 ; expire (3 weeks)
- 3600 ; minimum (1 hour)
- )
-@ NS ns3
-ns3 A 10.53.0.3
-;mail A 10.0.0.2 // the correct record
-@ A 10.0.0.3
+++ /dev/null
-/*
- * Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC")
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
- * REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
- * AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
- * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
- * LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
- * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
- * PERFORMANCE OF THIS SOFTWARE.
- */
-
-/* $Id: named.conf,v 1.2 2009/11/17 23:55:18 marka Exp $ */
-
-controls { /* empty */ };
-
-include "trusted.conf";
-
-options {
- query-source address 10.53.0.4;
- notify-source 10.53.0.4;
- transfer-source 10.53.0.4;
- port 5300;
- pid-file "named.pid";
- listen-on { 10.53.0.4; };
- listen-on-v6 { none; };
- recursion yes;
-};
-
-zone "." {
- type hint;
- file "../../common/root.hint";
-};
+++ /dev/null
-#!/bin/sh -e
-#
-# Copyright (C) 2009 Internet Systems Consortium, Inc. ("ISC")
-#
-# Permission to use, copy, modify, and/or distribute this software for any
-# purpose with or without fee is hereby granted, provided that the above
-# copyright notice and this permission notice appear in all copies.
-#
-# THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
-# REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
-# AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
-# INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
-# LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
-# OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
-# PERFORMANCE OF THIS SOFTWARE.
-
-# $Id: setup.sh,v 1.2 2009/11/17 23:55:18 marka Exp $
-
-../../../tools/genrandom 400 random.data
-
-cd ns1 && sh -e sign.sh
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-DNS Extensions Working Group S. Rose
-Internet-Draft NIST
-Obsoletes: 2672 (if approved) W. Wijngaards
-Updates: 3363,4294 NLnet Labs
-(if approved) November 12, 2009
-Intended status: Standards Track
-Expires: May 16, 2010
-
-
- Update to DNAME Redirection in the DNS
- draft-ietf-dnsext-rfc2672bis-dname-18
-
-Abstract
-
- The DNAME record provides redirection for a sub-tree of the domain
- name tree in the DNS system. That is, all names that end with a
- particular suffix are redirected to another part of the DNS. This is
- a revision of the original specification in RFC 2672, also aligning
- RFC 3363 and RFC 4294 with this revision.
-
-Requirements Language
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-Status of This Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on May 16, 2010.
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 1]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the BSD License.
-
- This document may contain material from IETF Documents or IETF
- Contributions published or made publicly available before November
- 10, 2008. The person(s) controlling the copyright in some of this
- material may not have granted the IETF Trust the right to allow
- modifications of such material outside the IETF Standards Process.
- Without obtaining an adequate license from the person(s) controlling
- the copyright in such materials, this document may not be modified
- outside the IETF Standards Process, and derivative works of it may
- not be created outside the IETF Standards Process, except to format
- it for publication as an RFC or to translate it into languages other
- than English.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 2]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
-
- 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4
- 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5
- 2.3. DNAME Owner Name not Redirected Itself . . . . . . . . . . 6
- 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7
- 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7
-
- 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1. CNAME synthesis . . . . . . . . . . . . . . . . . . . . . 8
- 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8
- 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 10
- 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10
-
- 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 11
-
- 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 12
- 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 12
- 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12
- 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13
- 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 13
- 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 13
- 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 13
- 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 13
- 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 13
- 5.3.4.2. Valid Name Error Response Involving DNAME in
- Bitmap . . . . . . . . . . . . . . . . . . . . . . 14
- 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 14
-
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
-
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
-
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
-
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 3]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
-1. Introduction
-
- DNAME is a DNS Resource Record type originally defined in RFC 2672
- [RFC2672]. DNAME provides redirection from a part of the DNS name
- tree to another part of the DNS name tree.
-
- The DNAME RR and the CNAME RR [RFC1034] cause a lookup to
- (potentially) return data corresponding to a domain name different
- from the queried domain name. The difference between the two
- resource records is that the CNAME RR directs the lookup of data at
- its owner to another single name, a DNAME RR directs lookups for data
- at descendents of its owner's name to corresponding names under a
- different (single) node of the tree.
-
- Take for example, looking through a zone (see RFC 1034 [RFC1034],
- section 4.3.2, step 3) for the domain name "foo.example.com" and a
- DNAME resource record is found at "example.com" indicating that all
- queries under "example.com" be directed to "example.net". The lookup
- process will return to step 1 with the new query name of
- "foo.example.net". Had the query name been "www.foo.example.com" the
- new query name would be "www.foo.example.net".
-
- This document is a revision of the original specification of DNAME in
- RFC 2672 [RFC2672]. DNAME was conceived to help with the problem of
- maintaining address-to-name mappings in a context of network
- renumbering. With a careful set-up, a renumbering event in the
- network causes no change to the authoritative server that has the
- address-to-name mappings. Examples in practice are classless reverse
- address space delegations.
-
- Another usage of DNAME lies in aliasing of name spaces. For example,
- a zone administrator may want sub-trees of the DNS to contain the
- same information. Examples include punycode alternates for domain
- spaces.
-
- This revision to DNAME does not change the wire format or the
- handling of DNAME Resource Records. Discussion is added on problems
- that may be encountered when using DNAME.
-
-2. The DNAME Resource Record
-
-2.1. Format
-
- The DNAME RR has mnemonic DNAME and type code 39 (decimal). It is
- not class-sensitive.
-
-
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 4]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- Its RDATA is comprised of a single field, <target>, which contains a
- fully qualified domain name that must be sent in uncompressed form
- [RFC1035], [RFC3597]. The <target> field MUST be present. The
- presentation format of <target> is that of a domain name [RFC1035].
-
- <owner> <ttl> <class> DNAME <target>
-
- The effect of the DNAME RR is the substitution of the record's
- <target> for its owner name, as a suffix of a domain name. This
- substitution has to be applied for every DNAME RR found in the
- resolution process, which allows fairly lengthy valid chains of DNAME
- RRs.
-
- Details of the substitution process, methods to avoid conflicting
- resource records, and rules for specific corner cases are given in
- the following subsections.
-
-2.2. The DNAME Substitution
-
- When following RFC 1034 [RFC1034], section 4.3.2's algorithm's third
- step, "start matching down, label by label, in the zone" and a node
- is found to own a DNAME resource record a DNAME substitution occurs.
- The name being sought may be the original query name or a name that
- is the result of a CNAME resource record being followed or a
- previously encountered DNAME. As in the case when finding a CNAME
- resource record or NS resource record set, the processing of a DNAME
- will happen prior to finding the desired domain name.
-
- A DNAME substitution is performed by replacing the suffix labels of
- the name being sought matching the owner name of the DNAME resource
- record with the string of labels in the RDATA field. The matching
- labels end with the root label in all cases. Only whole labels are
- replaced. See the table of examples for common cases and corner
- cases.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 5]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- In the table below, the QNAME refers to the query name. The owner is
- the DNAME owner domain name, and the target refers to the target of
- the DNAME record. The result is the resulting name after performing
- the DNAME substitution on the query name. "no match" means that the
- query did not match the DNAME and thus no substitution is performed
- and a possible error message is returned (if no other result is
- possible). Thus every line contains one example substitution. In
- the examples below, 'cyc' and 'shortloop' contain loops.
-
- QNAME owner DNAME target result
- ---------------- -------------- -------------- -----------------
- com. example.com. example.net. <no match>
- example.com. example.com. example.net. <no match>
- a.example.com. example.com. example.net. a.example.net.
- a.b.example.com. example.com. example.net. a.b.example.net.
- ab.example.com. b.example.com. example.net. <no match>
- foo.example.com. example.com. example.net. foo.example.net.
- a.x.example.com. x.example.com. example.net. a.example.net.
- a.example.com. example.com. y.example.net. a.y.example.net.
- cyc.example.com. example.com. example.com. cyc.example.com.
- cyc.example.com. example.com. c.example.com. cyc.c.example.com.
- shortloop.x.x. x. . shortloop.x.
- shortloop.x. x. . shortloop.
-
- Table 1. DNAME Substitution Examples.
-
- It is possible for DNAMEs to form loops, just as CNAMEs can form
- loops. DNAMEs and CNAMEs can chain together to form loops. A single
- corner case DNAME can form a loop. Resolvers and servers should be
- cautious in devoting resources to a query, but be aware that fairly
- long chains of DNAMEs may be valid. Zone content administrators
- should take care to insure that there are no loops that could occur
- when using DNAME or DNAME/CNAME redirection.
-
- The domain name can get too long during substitution. For example,
- suppose the target name of the DNAME RR is 250 octets in length
- (multiple labels), if an incoming QNAME that has a first label over 5
- octets in length, the result would be a name over 255 octets. If
- this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The
- DNAME record and its signature (if the zone is signed) are included
- in the answer as proof for the YXDOMAIN (value 6) RCODE.
-
-2.3. DNAME Owner Name not Redirected Itself
-
- Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its
- owner name; the owner name of a DNAME is not redirected itself. The
- domain name that owns a DNAME record is allowed to have other
- resource record types at that domain name, except DNAMEs, CNAMEs or
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 6]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- other types that have restrictions on what they can co-exist with.
- DNAME RRs MUST NOT appear at the same owner name as an NS RR unless
- the owner name is the zone apex.
-
- If a DNAME record is present at the zone apex, there is still a need
- to have the customary SOA and NS resource records there as well.
- Such a DNAME cannot be used to mirror a zone completely, as it does
- not mirror the zone apex.
-
- These rules also allow DNAME records to be queried through RFC 1034
- [RFC1034] compliant, DNAME-unaware caches.
-
-2.4. Names Next to and Below a DNAME Record
-
- Resource records MUST NOT exist at any sub-domain of the owner of a
- DNAME RR. To get the contents for names subordinate to that owner
- name, the DNAME redirection must be invoked and the resulting target
- queried. A server MAY refuse to load a zone that has data at a sub-
- domain of a domain name owning a DNAME RR. If the server does load
- the zone, those names below the DNAME RR will be occluded as
- described in RFC 2136 [RFC2136], section 7.18. Also a server SHOULD
- refuse to load a zone subordinate to the owner of a DNAME record in
- the ancestor zone. See Section 5.2 for further discussion related to
- dynamic update.
-
- DNAME is a singleton type, meaning only one DNAME is allowed per
- name. The owner name of a DNAME can only have one DNAME RR, and no
- CNAME RRs can exist at that name. These rules make sure that for a
- single domain name only one redirection exists, and thus no confusion
- which one to follow. A server SHOULD refuse to load a zone that
- violates these rules.
-
-2.5. Compression of the DNAME record.
-
- The DNAME owner name can be compressed like any other owner name.
- The DNAME RDATA target name MUST NOT be sent out in compressed form,
- so that a DNAME RR can be treated as an unknown type [RFC3597].
-
- Although the previous DNAME specification [RFC2672] (that is
- obsoleted by this specification) talked about signaling to allow
- compression of the target name, such signaling has never been
- specified and this document also does not specify this signaling
- behavior.
-
- RFC 2672 (obsoleted by this document) stated that the EDNS version
- had a meaning for understanding of DNAME and DNAME target name
- compression. This document revises RFC 2672, in that there is no
- EDNS version signaling for DNAME.
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 7]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
-3. Processing
-
- The DNAME RR causes type NS additional section processing. This
- refers to action at step 6 of the server algorithm outlined in
- section 3.2.
-
-3.1. CNAME synthesis
-
- When preparing a response, a server performing a DNAME substitution
- will in all cases include the relevant DNAME RR in the answer
- section. A CNAME RR with TTL equal to the corresponding DNAME RR is
- synthesized and included in the answer section. The owner name of
- the CNAME is the QNAME of the query. The DNSSEC specification
- [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does
- not have to be signed. The DNAME has an RRSIG and a validating
- resolver can check the CNAME against the DNAME record and validate
- the signature over the DNAME RR.
-
- Resolvers MUST be able to handle a synthesized CNAME TTL of zero or
- equal to the TTL of the corresponding DNAME record. A TTL of zero
- means that the CNAME can be discarded immediately after processing
- the answer.
-
- Servers MUST be able to answer a query for a synthesized CNAME. Like
- other query types this invokes the DNAME, and synthesizes the CNAME
- into the answer.
-
-3.2. Server algorithm
-
- Below is the server algorithm, which appeared in RFC 2672 Section
- 4.1.
-
- 1. Set or clear the value of recursion available in the response
- depending on whether the name server is willing to provide
- recursive service. If recursive service is available and
- requested via the RD bit in the query, go to step 5, otherwise
- step 2.
-
-
- 2. Search the available zones for the zone which is the nearest
- ancestor to QNAME. If such a zone is found, go to step 3,
- otherwise step 4.
-
-
- 3. Start matching down, label by label, in the zone. The matching
- process can terminate several ways:
-
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 8]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- A. If the whole of QNAME is matched, we have found the node.
-
- If the data at the node is a CNAME, and QTYPE does not match
- CNAME, copy the CNAME RR into the answer section of the
- response, change QNAME to the canonical name in the CNAME RR,
- and go back to step 1.
-
- Otherwise, copy all RRs which match QTYPE into the answer
- section and go to step 6.
-
-
- B. If a match would take us out of the authoritative data, we
- have a referral. This happens when we encounter a node with
- NS RRs marking cuts along the bottom of a zone.
-
- Copy the NS RRs for the sub-zone into the authority section
- of the reply. Put whatever addresses are available into the
- additional section, using glue RRs if the addresses are not
- available from authoritative data or the cache. Go to step
- 4.
-
-
- C. If at some label, a match is impossible (i.e., the
- corresponding label does not exist), look to see whether the
- last label matched has a DNAME record.
-
- If a DNAME record exists at that point, copy that record into
- the answer section. If substitution of its <target> for its
- <owner> in QNAME would overflow the legal size for a <domain-
- name>, set RCODE to YXDOMAIN [RFC2136] and exit; otherwise
- perform the substitution and continue. The server MUST
- synthesize a CNAME record as described above and include it
- in the answer section. Go back to step 1.
-
- If there was no DNAME record, look to see if the "*" label
- exists.
-
- If the "*" label does not exist, check whether the name we
- are looking for is the original QNAME in the query or a name
- we have followed due to a CNAME or DNAME. If the name is
- original, set an authoritative name error in the response and
- exit. Otherwise just exit.
-
- If the "*" label does exist, match RRs at that node against
- QTYPE. If any match, copy them into the answer section, but
- set the owner of the RR to be QNAME, and not the node with
- the "*" label. If the data at the node with the "*" label is
- a CNAME, and QTYPE doesn't match CNAME, copy the CNAME RR
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 9]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- into the answer section of the response changing the owner
- name to the QNAME, change QNAME to the canonical name in the
- CNAME RR, and go back to step 1. Otherwise, Go to step 6.
-
-
- 4. Start matching down in the cache. If QNAME is found in the
- cache, copy all RRs attached to it that match QTYPE into the
- answer section. If QNAME is not found in the cache but a DNAME
- record is present at an ancestor of QNAME, copy that DNAME record
- into the answer section. If there was no delegation from
- authoritative data, look for the best one from the cache, and put
- it in the authority section. Go to step 6.
-
-
- 5. Use the local resolver or a copy of its algorithm to answer the
- query. Store the results, including any intermediate CNAMEs and
- DNAMEs, in the answer section of the response.
-
-
- 6. Using local data only, attempt to add other RRs which may be
- useful to the additional section of the query. Exit.
-
- Note that there will be at most one ancestor with a DNAME as
- described in step 4 unless some zone's data is in violation of the
- no-descendants limitation in section 3. An implementation might take
- advantage of this limitation by stopping the search of step 3c or
- step 4 when a DNAME record is encountered.
-
-3.3. Wildcards
-
- The use of DNAME in conjunction with wildcards is discouraged
- [RFC4592]. Thus records of the form "*.example.com DNAME
- example.net" SHOULD NOT be used.
-
- The interaction between the expansion of the wildcard and the
- redirection of the DNAME is non-deterministic. Because the
- processing is non-deterministic, DNSSEC validating resolvers may not
- be able to validate a wildcarded DNAME.
-
- A server MAY give a warning that the behavior is unspecified if such
- a wildcarded DNAME is loaded. The server MAY refuse it, refuse to
- load the zone or refuse dynamic updates.
-
-3.4. Acceptance and Intermediate Storage
-
- Recursive caching name servers can encounter data at names below the
- owner name of a DNAME RR, due to a change at the authoritative server
- where data from before and after the change resides in the cache.
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 10]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- This conflict situation is a transitional phase that ends when the
- old data times out. The caching name server can opt to store both
- old and new data and treat each as if the other did not exist, or
- drop the old data, or drop the longer domain name. In any approach,
- consistency returns after the older data TTL times out.
-
- Recursive caching name servers MUST perform CNAME synthesis on behalf
- of clients.
-
- If a recursive caching name server encounters a DNAME RR which
- contradicts information already in the cache (excluding CNAME
- records), it SHOULD NOT cache the DNAME RR, but it MAY cache the
- CNAME record received along with it, subject to the rules for CNAME.
-
-4. DNAME Discussions in Other Documents
-
- In [RFC2181], in Section 10.3., the discussion on MX and NS records
- touches on redirection by CNAMEs, but this also holds for DNAMEs.
-
- Excerpt from 10.3. MX and NS records (in RFC 2181).
-
- The domain name used as the value of a NS resource record,
- or part of the value of a MX resource record must not be
- an alias. Not only is the specification clear on this
- point, but using an alias in either of these positions
- neither works as well as might be hoped, nor well fulfills
- the ambition that may have led to this approach. This
- domain name must have as its value one or more address
- records. Currently those will be A records, however in
- the future other record types giving addressing
- information may be acceptable. It can also have other
- RRs, but never a CNAME RR.
-
- The DNAME RR is discussed in RFC 3363, section 4, on A6 and DNAME.
- The opening premise of this section is demonstrably wrong, and so the
- conclusion based on that premise is wrong. In particular, [RFC3363]
- deprecates the use of DNAME in the IPv6 reverse tree, which is then
- carried forward as a recommendation in [RFC4294]. Based on the
- experience gained in the meantime, [RFC3363] should be revised,
- dropping all constraints on having DNAME RRs in these zones. This
- would greatly improve the manageability of the IPv6 reverse tree.
- These changes are made explicit below.
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 11]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- In [RFC3363], the paragraph
-
- "The issues for DNAME in the reverse mapping tree appears to be
- closely tied to the need to use fragmented A6 in the main tree: if
- one is necessary, so is the other, and if one isn't necessary, the
- other isn't either. Therefore, in moving RFC 2874 to experimental,
- the intent of this document is that use of DNAME RRs in the reverse
- tree be deprecated."
-
- is to be replaced with the word "DELETED".
-
- In [RFC4294], the reference to DNAME was left in as an editorial
- oversight. The paragraph
-
- "Those nodes are NOT RECOMMENDED to support the experimental A6 and
- DNAME Resource Records [RFC3363]."
-
- is to be replaced by
-
- "Those nodes are NOT RECOMMENDED to support the experimental
- A6 Resource Record [RFC3363]."
-
-5. Other Issues with DNAME
-
- There are several issues to be aware of about the use of DNAME.
-
-5.1. Canonical hostnames cannot be below DNAME owners
-
- The names listed as target names of MX, NS, PTR and SRV [RFC2782]
- records must be canonical hostnames. This means no CNAME or DNAME
- redirection may be present during DNS lookup of the address records
- for the host. This is discussed in RFC 2181 [RFC2181], section 10.3,
- and RFC 1912 [RFC1912], section 2.4. For SRV see RFC 2782 [RFC2782]
- page 4.
-
- The upshot of this is that although the lookup of a PTR record can
- involve DNAMEs, the name listed in the PTR record can not fall under
- a DNAME. The same holds for NS, SRV and MX records. For example,
- when punycode alternates for a zone use DNAME then the NS, MX, SRV
- and PTR records that point to that zone must use names without
- punycode in their RDATA. What must be done then is to have the
- domain names with DNAME substitution already applied to it as the MX,
- NS, PTR, SRV data. These are valid canonical hostnames.
-
-5.2. Dynamic Update and DNAME
-
- DNAME records can be added, changed and removed in a zone using
- dynamic update transactions. Adding a DNAME RR to a zone occludes
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 12]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- any domain names that may exist under the added DNAME.
-
- A server MUST reject a dynamic update message that attempts to add a
- DNAME RR at a name that already has a CNAME RR or another DNAME RR
- associated with that name.
-
-5.3. DNSSEC and DNAME
-
- The following subsections specify the behavior of implementations
- that understand both DNSSEC and DNAME (synthesis).
-
-5.3.1. Signed DNAME, Unsigned Synthesized CNAME
-
- In any response, a signed DNAME RR indicates a non-terminal
- redirection of the query. There might or might not be a server
- synthesized CNAME in the answer section; if there is, the CNAME will
- never be signed. For a DNSSEC validator, verification of the DNAME
- RR and then checking that the CNAME was properly synthesized is
- sufficient proof.
-
-5.3.2. DNAME Bit in NSEC Type Map
-
- In any negative response, the NSEC or NSEC3 [RFC5155] record type bit
- map SHOULD be checked to see that there was no DNAME that could have
- been applied. If the DNAME bit in the type bit map is set and the
- query name is a subdomain of the closest encloser that is asserted,
- then DNAME substitution should have been done, but the substitution
- has not been done as specified.
-
-5.3.3. DNAME Chains as Strong as the Weakest Link
-
- A response can contain a chain of DNAME and CNAME redirections. That
- chain can end in a positive answer or a negative (no name error or no
- data error) reply. Each step in that chain results in resource
- records added to the answer or authority section of the response.
- Only if all steps are secure can the AD bit be set for the response.
- If one of the steps is bogus, the result is bogus.
-
-5.3.4. Validators Must Understand DNAME
-
- Below are examples of why DNSSEC validators MUST understand DNAME.
- In the examples below, SOA records, wildcard denial NSECs and other
- material not under discussion has been omitted.
-
-5.3.4.1. DNAME in Bitmap Causes Invalid Name Error
-
-
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 13]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- ;; Header: QR AA DO RCODE=3(NXDOMAIN)
- ;; Question
- foo.bar.example.com. IN A
- ;; Authority
- bar.example.com. NSEC dub.example.com. A DNAME
- bar.example.com. RRSIG NSEC [valid signature]
-
- If this is the received response, then only by understanding that the
- DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to
- have been redirected by the DNAME, the validator can see that it is a
- BOGUS reply from an attacker that collated existing records from the
- DNS to create a confusing reply.
-
- If the DNAME bit had not been set in the NSEC record above then the
- answer would have validated as a correct name error response.
-
-5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap
-
- ;; Header: QR AA DO RCODE=3(NXDOMAIN)
- ;; Question
- cee.example.com. IN A
- ;; Authority
- bar.example.com. NSEC dub.example.com. A DNAME
- bar.example.com. RRSIG NSEC [valid signature]
-
- This response has the same NSEC records as the example above, but
- with this query name (cee.example.com), the answer is validated,
- because 'cee' does not get redirected by the DNAME at 'bar'.
-
-5.3.4.3. Response With Synthesized CNAME
-
- ;; Header: QR AA DO RCODE=0(NOERROR)
- ;; Question
- foo.bar.example.com. IN A
- ;; Answer
- bar.example.com. DNAME bar.example.net.
- bar.example.com. RRSIG DNAME [valid signature]
- foo.bar.example.com. CNAME foo.bar.example.net.
-
- The response shown above has the synthesized CNAME included.
- However, the CNAME has no signature, since the server does not sign
- online. So this response cannot be trusted. It could be altered by
- an attacker to be foo.bar.example.com CNAME bla.bla.example. The
- DNAME record does have its signature included, since it does not
- change. The validator must verify the DNAME signature and then
- recursively resolve further to query for the foo.bar.example.net A
- record.
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 14]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
-6. IANA Considerations
-
- The DNAME Resource Record type code 39 (decimal) originally has been
- registered by [RFC2672]. IANA should update the DNS resource record
- registry to point to this document for RR type 39.
-
-7. Security Considerations
-
- DNAME redirects queries elsewhere, which may impact security based on
- policy and the security status of the zone with the DNAME and the
- redirection zone's security status. For validating resolvers, the
- lowest security status of the links in the chain of CNAME and DNAME
- redirections is applied to the result.
-
- If a validating resolver accepts wildcarded DNAMEs, this creates
- security issues. Since the processing of a wildcarded DNAME is non-
- deterministic and the CNAME that was substituted by the server has no
- signature, the resolver may choose a different result than what the
- server meant, and consequently end up at the wrong destination. Use
- of wildcarded DNAMEs is discouraged in any case [RFC4592].
-
- A validating resolver MUST understand DNAME, according to [RFC4034].
- The examples in Section 5.3.4 illustrate this need.
-
-8. Acknowledgments
-
- The authors of this draft would like to acknowledge Matt Larson for
- beginning this effort to address the issues related to the DNAME RR
- type. The authors would also like to acknowledge Paul Vixie, Ed
- Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred
- Hoenes and Kevin Darcy for their review and comments on this
- document.
-
-9. References
-
-9.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 15]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
- RFC 2136, April 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
- System", RFC 4592, July 2006.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-9.2. Informative References
-
- [RFC1912] Barr, D., "Common DNS Operational and Configuration
- Errors", RFC 1912, February 1996.
-
- [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection",
- RFC 2672, August 1999.
-
- [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
- Hain, "Representing Internet Protocol version 6 (IPv6)
- Addresses in the Domain Name System (DNS)", RFC 3363,
- August 2002.
-
- [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
- April 2006.
-
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 16]
-\f
-Internet-Draft DNAME Redirection November 2009
-
-
-Authors' Addresses
-
- Scott Rose
- NIST
- 100 Bureau Dr.
- Gaithersburg, MD 20899
- USA
-
- Phone: +1-301-975-8439
- Fax: +1-301-975-6238
- EMail: scottr@nist.gov
-
-
- Wouter Wijngaards
- NLnet Labs
- Science Park 140
- Amsterdam 1098 XG
- The Netherlands
-
- Phone: +31-20-888-4551
- EMail: wouter@nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose & Wijngaards Expires May 16, 2010 [Page 17]
-\f
-
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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 "[<TTL>] [<class>]
- <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
-
-
-
-Expires March 2010 Standards Track [Page 3]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-DNSext Working Group F. Dupont
-Internet-Draft ISC
-Updates: 2845,2930,4635 May 8, 2009
-(if approved)
-Intended status: Standards Track
-Expires: November 9, 2009
-
-
- Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records
- draft-ietf-dnsext-tsig-md5-deprecated-03.txt
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79. This document may contain material
- from IETF Documents or IETF Contributions published or made publicly
- available before November 10, 2008. The person(s) controlling the
- copyright in some of this material may not have granted the IETF
- Trust the right to allow modifications of such material outside the
- IETF Standards Process. Without obtaining an adequate license from
- the person(s) controlling the copyright in such materials, this
- document may not be modified outside the IETF Standards Process, and
- derivative works of it may not be created outside the IETF Standards
- Process, except to format it for publication as an RFC or to
- translate it into languages other than English.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on November 9, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
-
-
-Dupont Expires November 9, 2009 [Page 1]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-Abstract
-
- The main purpose of this document is to deprecate the use of HMAC-MD5
- as an algorithm for the TSIG (secret key transaction authentication)
- resource record in the DNS (domain name system), and the use of MD5
- in TKEY (secret key establishment for DNS).
-
-
-1. Introduction
-
- The secret key transaction authentication for DNS (TSIG, [RFC2845])
- was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm.
- When the MD5 [RFC1321] security came to be considered lower than
- expected, [RFC4635] standardized new TSIG algorithms based on SHA
- [RFC3174][RFC3874][RFC4634] digests.
-
- But [RFC4635] did not deprecate the HMAC-MD5 algorithm. This
- document is targeted to complete the process, in detail:
- 1. Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm
- name registry managed by the IANA under the IETF Review Policy
- [RFC5226]
- 2. Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for
- implementations
- 3. Provide a keying material derivation for the secret key
- establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman
- exchange with SHA256 [RFC4634] in place of MD5 [RFC1321]
- 4. Finally recommend the use of HMAC-SHA256.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-2. Implementation Requirements
-
- The table of section 3 of [RFC4635] is replaced by:
-
-
-
-
-
-
-
-
-
-Dupont Expires November 9, 2009 [Page 2]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
- +-------------------+--------------------------+
- | Requirement Level | Algorithm Name |
- +-------------------+--------------------------+
- | Optional | HMAC-MD5.SIG-ALG.REG.INT |
- | Optional | gss-tsig |
- | Mandatory | hmac-sha1 |
- | Optional | hmac-sha224 |
- | Mandatory | hmac-sha256 |
- | Optional | hmac-sha384 |
- | Optional | hmac-sha512 |
- +-------------------+--------------------------+
-
- Implementations that support TSIG MUST also implement HMAC-SHA1 and
- HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level)
- and MAY implement GSS-TSIG and the other algorithms listed above
- (i.e., algorithms at a "not Mandatory" requirement level).
-
-
-3. TKEY keying material derivation
-
- When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying
- material is derived from the shared secret and TKEY resource record
- data using MD5 [RFC1321] at the end of section 4.1 page 9.
-
- This is amended into:
-
- keying material =
- XOR ( DH value, SHA256 ( query data | DH value ) |
- SHA256 ( server data | DH value ) )
-
- using the same conventions.
-
-
-4. IANA Consideration
-
- This document extends the "TSIG Algorithm Names - per [] and
- [RFC2845]" located at
- http://www.iana.org/assignments/tsig-algorithm-names by adding a new
- column to the registry "Compliance Requirement".
-
- The registry should contain the following:
-
-
-
-
-
-
-
-
-
-
-Dupont Expires November 9, 2009 [Page 3]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
- +--------------------------+------------------------+-------------+
- | Algorithm Name | Compliance Requirement | Reference |
- +--------------------------+------------------------+-------------+
- | gss-tsig | Optional | [RFC3645] |
- | HMAC-MD5.SIG-ALG.REG.INT | Optional | [][RFC2845] |
- | hmac-sha1 | Mandatory | [RFC4635] |
- | hmac-sha224 | Optional | [RFC4635] |
- | hmac-sha256 | Mandatory | [RFC4635] |
- | hmac-sha384 | Optional | [RFC4635] |
- | hmac-sha512 | Optional | [RFC4635] |
- +--------------------------+------------------------+-------------+
-
- where [] is this document.
-
-
-5. Availability Considerations
-
- MD5 is no longer universally available and its use may lead to
- increasing operation issues. SHA1 is likely to suffer from the same
- kind of problem. In summary MD5 has reached end-of-life and SHA1
- will likely follow in the near term.
-
- According to [RFC4635], implementations which support TSIG are
- REQUIRED to implement HMAC-SHA256.
-
-
-6. Security Considerations
-
- This document does not assume anything about the cryptographic
- security of different hash algorithms. Its purpose is a better
- availability of some security mechanisms in a predictable time frame.
-
- Requirement levels are adjusted for TSIG and related specifications
- (i.e., TKEY):
- The support of HMAC-MD5 is changed from mandatory to optional.
- The use of MD5 and HMAC-MD5 is NOT RECOMMENDED.
- The use of HMAC-SHA256 is RECOMMENDED.
-
-
-7. Acknowledgments
-
- Olafur Gudmundsson kindly helped in the procedure to deprecate the
- MD5 use in TSIG, i.e., the procedure which led to this memo. Alfred
- Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some
- improvements.
-
-
-8. References
-
-
-
-Dupont Expires November 9, 2009 [Page 4]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, BCP 14, March 1997.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers",
- RFC 4635, August 2006.
-
-8.2. Informative References
-
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104,
- February 1997.
-
- [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
- (SHA1)", RFC 3174, September 2001.
-
- [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
- and R. Hall, "Generic Security Service Algorithm for
- Secret Key Transaction Authentication for DNS (GSS-TSIG)",
- RFC 3645, October 2003.
-
- [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",
- RFC 3874, September 2004.
-
- [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
- (SHA and HMAC-SHA)", RFC 4634, July 2006.
-
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", RFC 5226, BCP 26,
- May 2008.
-
-
-
-
-
-
-
-
-
-
-Dupont Expires November 9, 2009 [Page 5]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
-Author's Address
-
- Francis Dupont
- ISC
-
- Email: Francis.Dupont@fdupont.fr
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dupont Expires November 9, 2009 [Page 6]
-\f
+++ /dev/null
-
-
-
-DNSOP W. Hardaker
-Internet-Draft Sparta, Inc.
-Intended status: Informational February 12, 2009
-Expires: August 16, 2009
-
-
- Requirements for Management of Name Servers for the DNS
- draft-ietf-dnsop-name-server-management-reqs-02.txt
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 16, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document.
-
-Abstract
-
- Management of name servers for the Domain Name Service (DNS) has
- traditionally been done using vendor-specific monitoring,
-
-
-
-Hardaker Expires August 16, 2009 [Page 1]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- configuration and control methods. Although some service monitoring
- platforms can test the functionality of the DNS itself there is not a
- interoperable way to manage (monitor, control and configure) the
- internal aspects of a name server itself.
-
- This document discusses the requirements of a management system for
- DNS name servers. A management solution that is designed to manage
- the DNS can use this document as a shopping list of needed features.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
- 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5
- 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5
- 2. Management Architecture Requirements . . . . . . . . . . . . . 5
- 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
- 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5
- 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
- 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
- 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
- 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
- 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
- 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
- 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
- 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
- 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
- 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
- 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
- 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
- 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
- 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
- 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
- 3.2.5. DNS Protocol Authorization Management . . . . . . . . 9
- 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
- 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10
- 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
- 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
- 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
- 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
- 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11
- 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
- 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
- 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
- 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
- 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
- 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
-
-
-
-Hardaker Expires August 16, 2009 [Page 2]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
- 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
- Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15
- A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
- A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
- A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 3]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-1. Introduction
-
- Management of name servers for the Domain Name Service (DNS)
- [RFC1034] [RFC1035] has traditionally been done using vendor-specific
- monitoring, configuration and control methods. Although some service
- monitoring platforms can test the functionality of the DNS itself
- there is not a interoperable way to manage (monitor, control and
- configure) the internal aspects of a name server itself.
-
- Previous standardization work within the IETF resulted in the
- creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
- to achieve significant implementation and deployment. The perceived
- reasons behind the failure for the two MIB modules are further
- documented in [RFC3197].
-
- This document discusses the requirements of a management system for
- DNS name servers. A management solution that is designed to manage
- the DNS can use this document as a shopping list of needed features.
-
- Specifically out of scope for this document are requirements
- associated with management of stub resolvers. It is not the intent
- of this document to document stub resolver requirements, although
- some of the requirements listed are applicable to stub resolvers as
- well.
-
- Also out of scope for this document is management of the host or
- other components of the host upon which the name server software is
- running. This document only discusses requirements for managing the
- name server component of a system.
-
- The task of creating a management system for managing DNS servers is
- not expected to be a small one. It is likely that components of the
- solution will need to be designed in parts over time and these
- requirements take this into consideration. In particular,
- Section 5.1 discusses the need for future extensibility of the base
- management solution. This document is intended to be a road-map
- towards a desired outcome and is not intended to define an "all-or-
- nothing" system. Successful interoperable management of name servers
- even in part is expected to be beneficial to network operators
- compared to the entirely custom solutions that are used at the time
- of this writing.
-
-1.1. Requirements notation
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 4]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-1.1.1. Terminology
-
- This document is consistent with the terminology defined in Section 2
- of [RFC4033]. Additional terminology needed for this document is
- described below:
-
- Name Server: When we are discussing servers that don't fall into a
- more specific type of server category defined in other documents,
- this document will refer to them generically as "name servers".
- In particular "name servers" can be considered to be any valid
- combination of authoritative, recursive, validating, or security-
- aware. The more specific name server labels will be used when
- this document refers only to a specific type of server. However,
- the term "name server", in this document, will not include stub
- resolvers.
-
-1.1.2. Document Layout and Requirements
-
- The document is written so that each numbered section will contain
- only a single requirement if it contains one at all. Each
- requirement will contain needed wording from the terminology
- described in Section 1.1. Subsections, however, might exist with
- additional related requirements. The document is laid out in this
- way so that a specific requirement can be uniquely referred to using
- the section number itself and the document version from which it
- came.
-
-
-2. Management Architecture Requirements
-
- This section discusses requirements that reflect the needs of the
- expected deployment environments.
-
-2.1. Expected Deployment Scenarios
-
- DNS zones vary greatly in the type of content published within them.
- Name Servers, too, are deployed with a wide variety of configurations
- to support the diversity of the deployed content. It is important
- that a management solution trying to meet the criteria specified in
- this document consider supporting the largest number of potential
- deployment cases as possible. Further deployment scenarios that are
- not used as direct examples of specific requirements are listed in
- Appendix A.
-
-2.1.1. Zone Size Constraints
-
- The management solution MUST support both name servers that are
- serving a small number of potentially very large zones (e.g. Top
-
-
-
-Hardaker Expires August 16, 2009 [Page 5]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- Level Domains (TLDs)) as well as name servers that are serving a very
- large number of small zones. These scenarios are both commonly seen
- deployments.
-
-2.1.2. Name Server Discovery
-
- Large enterprise network deployments may contain multiple name
- servers operating within the boundaries of the enterprise network.
- These name servers may each be serving multiple zones both in and out
- of the parent enterprise's zone. Finding and managing large
- quantities of name servers would be a useful feature of the resulting
- management solution. The management solution MAY support the ability
- to discover previously unknown instances of name servers operating
- within a deployed network.
-
-2.1.3. Configuration Data Volatility
-
- Configuration data is defined as data that relates only to the
- configuration of a server and the zones it serves. It specifically
- does not include data from the zone contents that is served through
- DNS itself. The solution MUST support servers that remain fairly
- statically configured over time as well as servers that have numerous
- zones being added and removed within an hour. Both of these
- scenarios are also commonly seen deployments.
-
-2.1.4. Protocol Selection
-
- There are many requirements in this document for many different types
- of management operations (see Section 3 for further details). It is
- possible that no one protocol will ideally fill all the needs of the
- requirements listed in this document and thus multiple protocols
- might be needed to produce a completely functional management system.
- Multiple protocols might be used to create the complete management
- solution, but the number of protocols used SHOULD be reduced to a
- reasonable minimum number.
-
-2.1.5. Common Data Model
-
- Defining a standardized protocol (or set of protocols) to use for
- managing name servers would be a step forward in achieving an
- interoperable management solution. However, just defining a protocol
- to use by itself would not achieve the complete end goal of a
- complete interoperable management solution. Devices also need to
- represent their internal management interface using a common
- management data model. The solution MUST create a common data model
- that management stations can make use of when sending or collecting
- data from a managed device so it can successfully manage equipment
- from vendors as if they were generic DNS servers. This common data
-
-
-
-Hardaker Expires August 16, 2009 [Page 6]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- model is needed for of the operations discussion in Section 3. Note
- that this does not preclude the fact that name server vendors might
- provide additional management infrastructure beyond a base management
- specification, as discussed further in Section 5.1.
-
-2.1.6. Operational Impact
-
- It is impossible to add new features to an existing server (such as
- the inclusion of a management infrastructure) and not impact the
- existing service and/or server in some fashion. At a minimum, for
- example, more memory, disk and/or CPU resources will be required to
- implement a new management system. However, the impact to the
- existing DNS service MUST be minimized since the DNS service itself
- is still the primary service to be offered by the modified name
- server.
-
-2.2. Name Server Types
-
- There are multiple ways in which name servers can be deployed. Name
- servers can take on any of the following roles:
-
- o Master Servers
-
- o Slave Servers
-
- o Recursive Servers
-
- The management solution SHOULD support all of these types of name
- servers as they are all equally important. Note that "Recursive
- Servers" can be further broken down by the security sub-roles they
- might implement, as defined in section 2 of [RFC4033]. These sub-
- roles are also important to support within any management solution.
-
- As stated earlier, the management of stub resolvers is considered out
- of scope for this documents.
-
-
-3. Management Operation Types
-
- Management operations can traditionally be broken into four
- categories:
-
- o Control
-
- o Configuration
-
- o Health and Monitoring
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 7]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- o Alarms and Events
-
- This section discusses requirements for each of these four management
- types in detail.
-
-3.1. Control Requirements
-
- The management solution MUST be capable of performing basic service
- control operations.
-
-3.1.1. Needed Control Operations
-
- These operations SHOULD include, at a minimum, the following
- operations:
-
- o Starting the name server
-
- o Reloading the service configuration
-
- o Reloading zone data
-
- o Restarting the name server
-
- o Stopping the name server
-
- Note that no restriction is placed on how the management system
- implements these operations. In particular, at least "starting the
- name server" will require a minimal management system component to
- exist independently of the name server itself.
-
-3.1.2. Asynchronous Status Notifications
-
- Some control operations might take a long time to complete. As an
- example, some name servers take a long time to perform reloads of
- large zones. Because of these timing issues, the management solution
- SHOULD take this into consideration and offer a mechanism to ease the
- burden associated with awaiting the status of a long-running command.
- This could, for example, result in the use of asynchronous
- notifications for returning the status of a long-running task or it
- might require the management station to poll for the status of a
- given task using monitoring commands. These and other potential
- solutions need to be evaluated carefully to select one that balances
- the result delivery needs with the perceived implementation costs.
-
- Also, see the related discussion in Section 3.4 on notification
- messages for supporting delivery of alarm and event messages.
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 8]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-3.2. Configuration Requirements
-
- Many features of name servers need to be configured before the server
- can be considered functional. The management solution MUST be able
- to provide name servers with configuration data. The most important
- data to be configured, for example, is the served zone data itself.
-
-3.2.1. Served Zone Modification
-
- The ability to add, modify and delete zones being served by name
- servers is needed. Although there are already solutions for zone
- content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
- AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
- might be used as part of the final management solution, the
- management system SHOULD still be able to natively create a new zone
- (with enough minimal data to allow the other mechanisms to function
- as well) as well as delete a zone. This might be, for example, a
- management operation that at least allows for the creation of the
- initial SOA record for a new zone as that's the minimum amount of
- zone data needed for the other operations to function.
-
-3.2.2. Trust Anchor Management
-
- The solution SHOULD support the ability to add, modify and delete
- trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
- [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust
- anchors might be configured using the data from the DNSKEY Resource
- Records (RRs) themselves or by using Delegation Signer (DS)
- fingerprints.
-
-3.2.3. Security Expectations
-
- DNSSEC Validating resolvers need to make policy decisions about the
- requests being processed. For example, they need to be configured
- with a list of zones expected to be secured by DNSSEC. The
- management solution SHOULD be able to add, modify and delete
- attributes of DNSSEC security policies.
-
-3.2.4. TSIG Key Management
-
- TSIG [RFC2845] allows transaction level authentication of DNS
- traffic. The management solution SHOULD be able to add, modify and
- delete TSIG keys known to the name server.
-
-3.2.5. DNS Protocol Authorization Management
-
- The management solution SHOULD have the ability to add, modify and
- delete authorization settings for the DNS protocols itself. Do not
-
-
-
-Hardaker Expires August 16, 2009 [Page 9]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- confuse this with the ability to manage the authorization associated
- with the management protocol itself, which is discussed later in
- Section 4.4. There are a number of authorization settings that are
- used by a name server. Example authorization settings that the
- solution might need to cover are:
-
- o Access to operations on zone data (e.g. DDNS)
-
- o Access to certain zone data from certain sources (e.g. from
- particular network subnets)
-
- o Access to specific DNS protocol services (e.g. recursive service)
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed authorization
- protections.
-
-3.3. Monitoring Requirements
-
- Monitoring is the process of collecting aspects of the internal state
- of a name server at a given moment in time. The solution MUST be
- able to monitor the health of a name server to determine its
- operational status, load and other internal attributes. Example
- management tasks that the solution might need to cover are:
-
- o Number of requests sent, responses sent, average response latency
- and other performance counters
-
- o Server status (e.g. "serving data", "starting up", "shutting
- down", ...)
-
- o Access control violations
-
- o List of zones being served
-
- o Detailed statistics about clients interacting with the name server
- (e.g. top 10 clients requesting data).
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed monitoring operations.
- In particular, some monitoring statistics are expected to be
- computationally or resource expensive and are considered to be "nice
- to haves" as opposed to "necessary to have".
-
-3.4. Alarm and Event Requirements
-
- Events occurring at the name server that trigger alarm notifications
- can quickly inform a management station about critical issues. A
-
-
-
-Hardaker Expires August 16, 2009 [Page 10]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- management solution SHOULD include support for delivery of alarm
- conditions.
-
- Example alarm conditions might include:
-
- o The server's status is changing. (e.g it is starting up, reloading
- configuration, restarting or shutting down)
-
- o A needed resource (e.g. memory or disk space) is exhausted or
- nearing exhaustion
-
- o An authorization violation was detected
-
- o The server has not received any data traffic (e.g. DNS requests
- or NOTIFYs) recently (AKA the "lonely warning"). This condition
- might indicate a problem with its deployment.
-
-
-4. Security Requirements
-
- The management solution will need to be appropriately secured against
- attacks on the management infrastructure.
-
-4.1. Authentication
-
- The solution MUST support mutual authentication. The management
- client needs to be assured that the management operations are being
- transferred to and from the correct name server. The managed name
- server needs to authenticate the system that is accessing the
- management infrastructure within itself.
-
-4.2. Integrity Protection
-
- Management operations MUST be protected from modification while in
- transit from the management client to the server.
-
-4.3. Confidentiality
-
- The management solution MUST support message confidentiality. The
- potential transfer of sensitive configuration is expected (such as
- TSIG keys or security policies). The solution does not, however,
- necessarily need to provide confidentiality to data that would
- normally be carried without confidentiality by the DNS system itself.
-
-4.4. Authorization
-
- The solution SHOULD be capable of providing a fine-grained
- authorization model for any management protocols it introduces to the
-
-
-
-Hardaker Expires August 16, 2009 [Page 11]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- completed system. This authorization differs from the authorization
- previously discussed in Section 3.2.5 in that this requirement is
- concerned solely with authorization of the management system itself.
-
- There are a number of authorization settings that might be used by a
- managed system to determine whether the managing entity has
- authorization to perform the given management task. Example
- authorization settings that the solution might need to cover are:
-
- o Access to the configuration that specifies which zones are to be
- served
-
- o Access to the management system infrastructure
-
- o Access to other control operations
-
- o Access to other configuration operations
-
- o Access to monitoring operations
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed authorization
- protections.
-
-4.5. Solution Impacts on Security
-
- The solution MUST minimize the security risks introduced to the
- complete name server system. It is impossible to add new
- infrastructure to a server and not impact the security in some
- fashion as the introduction of a management protocol alone will
- provide a new avenue for potential attack. Although the added
- management benefits will be worth the increased risks, the solution
- still needs to minimize this impact as much as possible.
-
-
-5. Other Requirements
-
-5.1. Extensibility
-
- The management solution is expected to change and expand over time as
- lessons are learned and new DNS features are deployed. Thus, the
- solution MUST be flexible and be able to accommodate new future
- management operations. The solution might, for example, make use of
- protocol versioning or capability description exchanges to ensure
- that management stations and name servers that weren't written to the
- same specification version can still interoperate to the best of
- their combined ability.
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 12]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-5.1.1. Vendor Extensions
-
- It MUST be possible for vendors to extend the standardized management
- model with vendor-specific extensions to support additional features
- offered by their products.
-
-5.1.2. Extension Identification
-
- It MUST be possible for a management station to understand which
- parts of returned data are specific to a given vendor or other
- standardized extension. The data returned needs to be appropriately
- marked through the use of name spaces or similar mechanisms to ensure
- that the base management model data can be logically separated from
- extension data without needing to understand the extension data
- itself.
-
-5.1.3. Name-Space Collision Protection
-
- It MUST be possible to protect against multiple extensions
- conflicting with each other. The use of name-space protection
- mechanisms for communicated management variables is common practice
- to protect against problems. Name-space identification techniques
- also frequently solve the "Extension Identification" requirement
- discussed in Section 5.1.2 as well.
-
-
-6. Security Considerations
-
- Any management protocol that meets the criteria discussed in this
- document needs to support the criteria discussed in Section 4 in
- order to protect the management infrastructure itself. The DNS is a
- core Internet service and management traffic that protects it could
- be the target of attacks designed to subvert that service. Because
- the management infrastructure will be adding additional interfaces to
- that service, it is critical that the management infrastructure
- support adequate protections against network attacks.
-
-
-7. IANA Considerations
-
- No action is required from IANA for this document.
-
-
-8. Document History
-
- A requirement gathering discussion was held at the December 2007 IETF
- meeting in Vancouver, BC, Canada and a follow up meeting was held at
- the March 2008 IETF meeting in Philadelphia. This document is a
-
-
-
-Hardaker Expires August 16, 2009 [Page 13]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- compilation of the results of those discussions as well as
- discussions on the DCOMA mailing list.
-
-
-9. Acknowledgments
-
- This draft is the result of discussions within the DCOMA design team
- chaired by Jaap Akkerhuis. This team consisted of a large number of
- people all of whom provided valuable insight and input into the
- discussions surrounding name server management. The text of this
- document was written from notes taken during meetings as well as from
- contributions sent to the DCOMA mailing list. This work documents
- the consensus of the DCOMA design team.
-
- In particular, the following team members contributed significantly
- to the text in the document:
-
- Stephane Bortzmeyer
-
- Stephen Morris
-
- Phil Regnauld
-
- Further editing contributions and wording suggestions were made by:
- Alfred Hoenes.
-
-
-10. References
-
-10.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
- August 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-
-
-
-Hardaker Expires August 16, 2009 [Page 14]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
- Trust Anchors", RFC 5011, September 2007.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-10.2. Informative References
-
- [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
- RFC 1611, May 1994.
-
- [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
- RFC 1612, May 1994.
-
- [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
- and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
- July 1997.
-
- [RFC3197] Austein, R., "Applicability Statement for DNS MIB
- Extensions", RFC 3197, November 2001.
-
-
-Appendix A. Deployment Scenarios
-
- This appendix documents some additional deployment scenarios that
- have been traditionally difficult to manage. They are provided as
-
-
-
-Hardaker Expires August 16, 2009 [Page 15]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- guidance to protocol developers as data points of real-world name
- server management problems.
-
-A.1. Non-Standard Zones
-
- If an organization uses non-standard zones (for example a purely-
- local TLD), synchronizing all the name servers for these zones is
- usually a time-consuming task. It is made worse when two
- organizations with conflicting zones merge. This situation is not a
- recommended deployment scenario (and is even heavily discouraged) but
- it is, unfortunately, seen in the wild.
-
- It is typically implemented using "forwarding" zones. But there is
- no way to ensure automatically that all the resolvers have the same
- set of zones to forward at any given time. New zones might be added
- to a local forwarding recursive server, for example, without
- modifying the rest of the deployed forwarding servers. It is hoped
- that a management solution which could handle the configuration of
- zone forwarding would finally allow management of servers deployed in
- this fashion.
-
-A.2. Redundancy Sharing
-
- For reliability reasons it is recommended that zone operators follow
- the guidelines documented in [RFC2182] which recommends that multiple
- name servers be configured for each zone and that the name servers
- are separated both physically and via connectivity routes. A common
- solution is to establish DNS-serving partnerships: "I'll host your
- zones and you'll host mine". Both entities benefit from increased
- DNS reliability via the wider service distribution. This frequently
- occurs between cooperating but otherwise unrelated entities (such as
- between two distinct companies) as well as between affiliated
- organizations (such as between branch offices within a single
- company).
-
- The configuration of these relationships are currently required to be
- manually configured and maintained. Changes to the list of zones
- that are cross-hosted are manually negotiated between the cooperating
- network administrators and configured by hand. A management protocol
- with the ability to provide selective authorization, as discussed in
- Section 4.4, would solve many of the management difficulties between
- cooperating organizations.
-
-A.3. DNSSEC Management
-
- There are many different DNSSEC deployment strategies that may be
- used for mission-critical zones. The following list describes some
- example deployment scenarios that might warrant different management
-
-
-
-Hardaker Expires August 16, 2009 [Page 16]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- strategies.
-
- All contents and DNSSEC keying information controlled and operated
- by a single organization
-
- Zone contents controlled and operated by one organization, all
- DNSSEC keying information controlled and operated by a second
- organization.
-
- Zone contents controlled and operated by one organization, zone
- signing keys (ZSKs) controlled and operated by a second
- organization, and key signing keys (KSKs) controlled and operated
- by a third organization.
-
- Although this list is not exhaustive in the potential ways that zone
- data can be divided up, it should be sufficient to illustrate the
- potential ways in which zone data can be controlled by multiple
- entities.
-
- The end result of all of these strategies, however, will be the same:
- a live zone containing DNSSEC related resource records. Many of the
- above strategies are merely different ways of preparing a zone for
- serving. A management solution that includes support for managing
- DNSSEC zone data may wish to take into account these potential
- management scenarios.
-
-
-Author's Address
-
- Wes Hardaker
- Sparta, Inc.
- P.O. Box 382
- Davis, CA 95617
- US
-
- Phone: +1 530 792 1913
- Email: ietf@hardakers.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 17]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group W. Hardaker
-Request for Comments: 4509 Sparta
-Category: Standards Track May 2006
-
-
- Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
-
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document specifies how to use the SHA-256 digest type in DNS
- Delegation Signer (DS) Resource Records (RRs). DS records, when
- stored in a parent zone, point to DNSKEYs in a child zone.
-
-Table of Contents
-
- 1. Introduction ....................................................2
- 2. Implementing the SHA-256 Algorithm for DS Record Support ........2
- 2.1. DS Record Field Values .....................................2
- 2.2. DS Record with SHA-256 Wire Format .........................3
- 2.3. Example DS Record Using SHA-256 ............................3
- 3. Implementation Requirements .....................................3
- 4. Deployment Considerations .......................................4
- 5. IANA Considerations .............................................4
- 6. Security Considerations .........................................4
- 6.1. Potential Digest Type Downgrade Attacks ....................4
- 6.2. SHA-1 vs SHA-256 Considerations for DS Records .............5
- 7. Acknowledgements ................................................5
- 8. References ......................................................6
- 8.1. Normative References .......................................6
- 8.2. Informative References .....................................6
-
-
-
-
-
-
-
-
-Hardaker Standards Track [Page 1]
-\f
-RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
-
-
-1. Introduction
-
- The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
- zones to distribute a cryptographic digest of one key in a child's
- DNSKEY RRset. The DS RRset is signed by at least one of the parent
- zone's private zone data signing keys for each algorithm in use by
- the parent. Each signature is published in an RRSIG resource record,
- owned by the same domain as the DS RRset, with a type covered of DS.
-
- In this document, the key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
- and "OPTIONAL" are to be interpreted as described in [RFC2119].
-
-2. Implementing the SHA-256 Algorithm for DS Record Support
-
- This document specifies that the digest type code 2 has been assigned
- to SHA-256 [SHA256] [SHA256CODE] for use within DS records. The
- results of the digest algorithm MUST NOT be truncated, and the entire
- 32 byte digest result is to be published in the DS record.
-
-2.1. DS Record Field Values
-
- Using the SHA-256 digest algorithm within a DS record will make use
- of the following DS-record fields:
-
- Digest type: 2
-
- Digest: A SHA-256 bit digest value calculated by using the following
- formula ("|" denotes concatenation). The resulting value is not
- truncated, and the entire 32 byte result is to be used in the
- resulting DS record and related calculations.
-
- digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
-
- where DNSKEY RDATA is defined by [RFC4034] as:
-
- DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
-
- The Key Tag field and Algorithm fields remain unchanged by this
- document and are specified in the [RFC4034] specification.
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Standards Track [Page 2]
-\f
-RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
-
-
-2.2. DS Record with SHA-256 Wire Format
-
- The resulting on-the-wire format for the resulting DS record will be
- as follows:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Key Tag | Algorithm | DigestType=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / /
- / Digest (length for SHA-256 is 32 bytes) /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-2.3. Example DS Record Using SHA-256
-
- The following is an example DNSKEY and matching DS record. This
- DNSKEY record comes from the example DNSKEY/DS records found in
- section 5.4 of [RFC4034].
-
- The DNSKEY record:
-
- dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
- fwJr1AYtsmx3TGkJaNXVbfi/
- 2pHm822aJ5iI9BMzNXxeYCmZ
- DRD99WYwYqUSdjMmmAphXdvx
- egXd/M5+X7OrzKBaMbCVdFLU
- Uh6DhweJBjEVv5f2wwjM9Xzc
- nOf+EPbtG9DMBmADjFDc2w/r
- ljwvFw==
- ) ; key id = 60485
-
- The resulting DS record covering the above DNSKEY record using a
- SHA-256 digest:
-
- dskey.example.com. 86400 IN DS 60485 5 2 ( D4B7D520E7BB5F0F67674A0C
- CEB1E3E0614B93C4F9E99B83
- 83F6A1E4469DA50A )
-
-3. Implementation Requirements
-
- Implementations MUST support the use of the SHA-256 algorithm in DS
- RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
- digests if DS RRs with SHA-256 digests are present in the DS RRset.
-
-
-
-
-
-
-Hardaker Standards Track [Page 3]
-\f
-RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
-
-
-4. Deployment Considerations
-
- If a validator does not support the SHA-256 digest type and no other
- DS RR exists in a zone's DS RRset with a supported digest type, then
- the validator has no supported authentication path leading from the
- parent to the child. The resolver should treat this case as it would
- the case of an authenticated NSEC RRset proving that no DS RRset
- exists, as described in [RFC4035], Section 5.2.
-
- Because zone administrators cannot control the deployment speed of
- support for SHA-256 in validators that may be referencing any of
- their zones, zone operators should consider deploying both SHA-1 and
- SHA-256 based DS records. This should be done for every DNSKEY for
- which DS records are being generated. Whether to make use of both
- digest types and for how long is a policy decision that extends
- beyond the scope of this document.
-
-5. IANA Considerations
-
- Only one IANA action is required by this document:
-
- The Digest Type to be used for supporting SHA-256 within DS records
- has been assigned by IANA.
-
- At the time of this writing, the current digest types assigned for
- use in DS records are as follows:
-
- VALUE Digest Type Status
- 0 Reserved -
- 1 SHA-1 MANDATORY
- 2 SHA-256 MANDATORY
- 3-255 Unassigned -
-
-6. Security Considerations
-
-6.1. Potential Digest Type Downgrade Attacks
-
- A downgrade attack from a stronger digest type to a weaker one is
- possible if all of the following are true:
-
- o A zone includes multiple DS records for a given child's DNSKEY,
- each of which uses a different digest type.
-
- o A validator accepts a weaker digest even if a stronger one is
- present but invalid.
-
-
-
-
-
-
-Hardaker Standards Track [Page 4]
-\f
-RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
-
-
- For example, if the following conditions are all true:
-
- o Both SHA-1 and SHA-256 based digests are published in DS records
- within a parent zone for a given child zone's DNSKEY.
-
- o The DS record with the SHA-1 digest matches the digest computed
- using the child zone's DNSKEY.
-
- o The DS record with the SHA-256 digest fails to match the digest
- computed using the child zone's DNSKEY.
-
- Then, if the validator accepts the above situation as secure, then
- this can be used as a downgrade attack since the stronger SHA-256
- digest is ignored.
-
-6.2. SHA-1 vs. SHA-256 Considerations for DS Records
-
- Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
- implementations allow for it. SHA-256 is widely believed to be more
- resilient to attack than SHA-1, and confidence in SHA-1's strength is
- being eroded by recently announced attacks. Regardless of whether
- the attacks on SHA-1 will affect DNSSEC, it is believed (at the time
- of this writing) that SHA-256 is the better choice for use in DS
- records.
-
- At the time of this publication, the SHA-256 digest algorithm is
- considered sufficiently strong for the immediate future. It is also
- considered sufficient for use in DNSSEC DS RRs for the immediate
- future. However, future published attacks may weaken the usability
- of this algorithm within the DS RRs. It is beyond the scope of this
- document to speculate extensively on the cryptographic strength of
- the SHA-256 digest algorithm.
-
- Likewise, it is also beyond the scope of this document to specify
- whether or for how long SHA-1 based DS records should be
- simultaneously published alongside SHA-256 based DS records.
-
-7. Acknowledgements
-
- This document is a minor extension to the existing DNSSEC documents
- and those authors are gratefully appreciated for the hard work that
- went into the base documents.
-
- The following people contributed to portions of this document in some
- fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
- Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
- Weiler.
-
-
-
-
-Hardaker Standards Track [Page 5]
-\f
-RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
-
-
-8. References
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC
- 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security
- Extensions", RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [SHA256] National Institute of Standards and Technology, "Secure
- Hash Algorithm. NIST FIPS 180-2", August 2002.
-
-8.2. Informative References
-
- [SHA256CODE] Eastlake, D., "US Secure Hash Algorithms (SHA)", Work in
- Progress.
-
-Author's Address
-
- Wes Hardaker
- Sparta
- P.O. Box 382
- Davis, CA 95617
- USA
-
- EMail: hardaker@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Standards Track [Page 6]
-\f
-RFC 4509 Use of SHA-256 in DNSSEC DS RRs May 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Hardaker Standards Track [Page 7]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group D. Eastlake 3rd
-Request for Comments: 4635 Motorola Laboratories
-Category: Standards Track August 2006
-
-
- HMAC SHA TSIG Algorithm Identifiers
-
- Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- Use of the Domain Name System TSIG resource record requires
- specification of a cryptographic message authentication code.
- Currently, identifiers have been specified only for HMAC MD5 (Hashed
- Message Authentication Code, Message Digest 5) and GSS (Generic
- Security Service) TSIG algorithms. This document standardizes
- identifiers and implementation requirements for additional HMAC SHA
- (Secure Hash Algorithm) TSIG algorithms and standardizes how to
- specify and handle the truncation of HMAC values in TSIG.
-
-Table of Contents
-
- 1. Introduction ....................................................2
- 2. Algorithms and Identifiers ......................................2
- 3. Specifying Truncation ...........................................3
- 3.1. Truncation Specification ...................................4
- 4. TSIG Truncation Policy and Error Provisions .....................4
- 5. IANA Considerations .............................................5
- 6. Security Considerations .........................................5
- 7. Normative References ............................................6
- 8. Informative References. .........................................7
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd Standards Track [Page 1]
-\f
-RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
-
-
-1. Introduction
-
- [RFC2845] specifies a TSIG Resource Record (RR) that can be used to
- authenticate DNS (Domain Name System [STD13]) queries and responses.
- This RR contains a domain name syntax data item that names the
- authentication algorithm used. [RFC2845] defines the
- HMAC-MD5.SIG-ALG.REG.INT name for authentication codes using the HMAC
- (Hashed Message Authentication Code) [RFC2104] algorithm with the MD5
- (Message Digest 5) [RFC1321] hash algorithm. IANA has also
- registered "gss-tsig" as an identifier for TSIG authentication where
- the cryptographic operations are delegated to the Generic Security
- Service (GSS) [RFC3645].
-
- Note that use of TSIG presumes prior agreement, between the resolver
- and server involved, as to the algorithm and key to be used.
-
- In Section 2, this document specifies additional names for TSIG
- authentication algorithms based on US NIST SHA (United States,
- National Institute of Science and Technology, Secure Hash Algorithm)
- algorithms and HMAC and specifies the implementation requirements for
- those algorithms.
-
- In Section 3, this document specifies the effect of inequality
- between the normal output size of the specified hash function and the
- length of MAC (Message Authentication Code) data given in the TSIG
- RR. In particular, it specifies that a shorter-length field value
- specifies truncation and that a longer-length field is an error.
-
- In Section 4, policy restrictions and implications related to
- truncation are described and specified, as is a new error code to
- indicate truncation shorter than that permitted by policy.
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", in
- this document are to be interpreted as described in [RFC2119].
-
-2. Algorithms and Identifiers
-
- TSIG Resource Records (RRs) [RFC2845] are used to authenticate DNS
- queries and responses. They are intended to be efficient symmetric
- authentication codes based on a shared secret. (Asymmetric
- signatures can be provided using the SIG RR [RFC2931]. In
- particular, SIG(0) can be used for transaction signatures.) Used
- with a strong hash function, HMAC [RFC2104] provides a way to
- calculate such symmetric authentication codes. The only specified
- HMAC-based TSIG algorithm identifier has been HMAC-MD5.SIG-
- ALG.REG.INT, based on MD5 [RFC1321].
-
-
-
-
-
-Eastlake 3rd Standards Track [Page 2]
-\f
-RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
-
-
- The use of SHA-1 [FIPS180-2, RFC3174], which is a 160-bit hash, as
- compared with the 128 bits for MD5, and additional hash algorithms in
- the SHA family [FIPS180-2, RFC3874, RFC4634] with 224, 256, 384, and
- 512 bits may be preferred in some cases. This is because
- increasingly successful cryptanalytic attacks are being made on the
- shorter hashes.
-
- Use of TSIG between a DNS resolver and server is by mutual agreement.
- That agreement can include the support of additional algorithms and
- criteria as to which algorithms and truncations are acceptable,
- subject to the restriction and guidelines in Sections 3 and 4 below.
- Key agreement can be by the TKEY mechanism [RFC2930] or some other
- mutually agreeable method.
-
- The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
- included in the table below for convenience. Implementations that
- support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
- implement gss-tsig and the other algorithms listed below.
-
- Mandatory HMAC-MD5.SIG-ALG.REG.INT
- Optional gss-tsig
- Mandatory hmac-sha1
- Optional hmac-sha224
- Mandatory hmac-sha256
- Optional hamc-sha384
- Optional hmac-sha512
-
- SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-3. Specifying Truncation
-
- When space is at a premium and the strength of the full length of an
- HMAC is not needed, it is reasonable to truncate the HMAC output and
- use the truncated value for authentication. HMAC SHA-1 truncated to
- 96 bits is an option available in several IETF protocols, including
- IPsec and TLS.
-
- The TSIG RR [RFC2845] includes a "MAC size" field, which gives the
- size of the MAC field in octets. However, [RFC2845] does not specify
- what to do if this MAC size differs from the length of the output of
- HMAC for a particular hash function. Truncation is indicated by a
- MAC size less than the HMAC size, as specified below.
-
-
-
-
-
-
-
-
-
-Eastlake 3rd Standards Track [Page 3]
-\f
-RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
-
-
-3.1. Truncation Specification
-
- The specification for TSIG handling is changed as follows:
-
- 1. If "MAC size" field is greater than HMAC output length:
-
- This case MUST NOT be generated and, if received, MUST cause
- the packet to be dropped and RCODE 1 (FORMERR) to be returned.
-
- 2. If "MAC size" field equals HMAC output length:
-
- Operation is as described in [RFC2845], and the entire output
- HMAC output is present.
-
- 3. "MAC size" field is less than HMAC output length but greater than
- that specified in case 4, below:
-
- This is sent when the signer has truncated the HMAC output to
- an allowable length, as described in RFC 2104, taking initial
- octets and discarding trailing octets. TSIG truncation can only
- be to an integral number of octets. On receipt of a packet with
- truncation thus indicated, the locally calculated MAC is similarly
- truncated and only the truncated values are compared for
- authentication. The request MAC used when calculating the TSIG
- MAC for a reply is the truncated request MAC.
-
- 4. "MAC size" field is less than the larger of 10 (octets) and half
- the length of the hash function in use:
-
- With the exception of certain TSIG error messages described in
- RFC 2845, Section 3.2, where it is permitted that the MAC size be
- zero, this case MUST NOT be generated and, if received, MUST cause
- the packet to be dropped and RCODE 1 (FORMERR) to be returned.
- The size limit for this case can also, for the hash functions
- mentioned in this document, be stated as less than half the hash
- function length for hash functions other than MD5 and less than 10
- octets for MD5.
-
-4. TSIG Truncation Policy and Error Provisions
-
- Use of TSIG is by mutual agreement between a resolver and server.
- Implicit in such "agreement" are criterion as to acceptable keys and
- algorithms and, with the extensions in this document, truncations.
- Note that it is common for implementations to bind the TSIG secret
- key or keys that may be in place at a resolver and server to
- particular algorithms. Thus, such implementations only permit the
-
-
-
-
-
-Eastlake 3rd Standards Track [Page 4]
-\f
-RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
-
-
- use of an algorithm if there is an associated key in place. Receipt
- of an unknown, unimplemented, or disabled algorithm typically results
- in a BADKEY error.
-
- Local policies MAY require the rejection of TSIGs, even though
- they use an algorithm for which implementation is mandatory.
-
- When a local policy permits acceptance of a TSIG with a particular
- algorithm and a particular non-zero amount of truncation, it SHOULD
- also permit the use of that algorithm with lesser truncation (a
- longer MAC) up to the full HMAC output.
-
- Regardless of a lower acceptable truncated MAC length specified by
- local policy, a reply SHOULD be sent with a MAC at least as long as
- that in the corresponding request, unless the request specified a MAC
- length longer than the HMAC output.
-
- Implementations permitting multiple acceptable algorithms and/or
- truncations SHOULD permit this list to be ordered by presumed
- strength and SHOULD allow different truncations for the same
- algorithm to be treated as separate entities in this list. When so
- implemented, policies SHOULD accept a presumed stronger algorithm and
- truncation than the minimum strength required by the policy.
-
- If a TSIG is received with truncation that is permitted under
- Section 3 above but the MAC is too short for the local policy in
- force, an RCODE of 22 (BADTRUNC) MUST be returned.
-
-5. IANA Considerations
-
- This document (1) registers the new TSIG algorithm identifiers listed
- in Section 2 with IANA and (2) allocates the BADTRUNC RCODE 22 in
- Section 4 [RFC2845].
-
-6. Security Considerations
-
- For all of the message authentication code algorithms listed herein,
- those producing longer values are believed to be stronger; however,
- while there have been some arguments that mild truncation can
- strengthen a MAC by reducing the information available to an
- attacker, excessive truncation clearly weakens authentication by
- reducing the number of bits an attacker has to try to break the
- authentication by brute force [RFC2104].
-
- Significant progress has been made recently in cryptanalysis of hash
- function of the types used herein, all of which ultimately derive
- from the design of MD4. While the results so far should not effect
-
-
-
-
-Eastlake 3rd Standards Track [Page 5]
-\f
-RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
-
-
- HMAC, the stronger SHA-1 and SHA-256 algorithms are being made
- mandatory due to caution.
-
- See the Security Considerations section of [RFC2845]. See also the
- Security Considerations section of [RFC2104] from which the limits on
- truncation in this RFC were taken.
-
-7. Normative References
-
- [FIPS180-2] "Secure Hash Standard", (SHA-1/224/256/384/512) US
- Federal Information Processing Standard, with Change
- Notice 1, February 2004.
-
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
- 1321, April 1992.
-
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
- Keyed-Hashing for Message Authentication", RFC 2104,
- February 1997.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
- Wellington, "Secret Key Transaction Authentication for
- DNS (TSIG)", RFC 2845, May 2000.
-
- [RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
- 1 (SHA1)", RFC 3174, September 2001.
-
- [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",
- RFC 3874, September 2004.
-
- [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
- (SHA)", RFC 4634, July 2006.
-
- [STD13] Mockapetris, P., "Domain names - concepts and
- facilities", STD 13, RFC 1034, November 1987.
-
- Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd Standards Track [Page 6]
-\f
-RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
-
-
-8. Informative References.
-
- [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
- ( SIG(0)s )", RFC 2931, September 2000.
-
- [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
- and R. Hall, "Generic Security Service Algorithm for
- Secret Key Transaction Authentication for DNS (GSS-
- TSIG)", RFC 3645, October 2003.
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Phone: +1-508-786-7554 (w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd Standards Track [Page 7]
-\f
-RFC 4635 HMAC SHA TSIG Algorithm Identifiers August 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Eastlake 3rd Standards Track [Page 8]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S. Woolf
-Request for Comments: 4892 Internet Systems Consortium, Inc.
-Category: Informational D. Conrad
- ICANN
- June 2007
-
-
- Requirements for a Mechanism Identifying a Name Server Instance
-
-Status of This Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-Abstract
-
- With the increased use of DNS anycast, load balancing, and other
- mechanisms allowing more than one DNS name server to share a single
- IP address, it is sometimes difficult to tell which of a pool of name
- servers has answered a particular query. A standardized mechanism to
- determine the identity of a name server responding to a particular
- query would be useful, particularly as a diagnostic aid for
- administrators. Existing ad hoc mechanisms for addressing this need
- have some shortcomings, not the least of which is the lack of prior
- analysis of exactly how such a mechanism should be designed and
- deployed. This document describes the existing convention used in
- some widely deployed implementations of the DNS protocol, including
- advantages and disadvantages, and discusses some attributes of an
- improved mechanism.
-
-1. Introduction and Rationale
-
- Identifying which name server is responding to queries is often
- useful, particularly in attempting to diagnose name server
- difficulties. This is most obviously useful for authoritative
- nameservers in the attempt to diagnose the source or prevalence of
- inaccurate data, but can also conceivably be useful for caching
- resolvers in similar and other situations. Furthermore, the ability
- to identify which server is responding to a query has become more
- useful as DNS has become more critical to more Internet users, and as
- network and server deployment topologies have become more complex.
-
-
-
-
-
-Woolf & Conrad Informational [Page 1]
-\f
-RFC 4892 Serverid June 2007
-
-
- The conventional means for determining which of several possible
- servers is answering a query has traditionally been based on the use
- of the server's IP address as a unique identifier. However, the
- modern Internet has seen the deployment of various load balancing,
- fault-tolerance, or attack-resistance schemes such as shared use of
- unicast IP addresses as documented in [RFC3258]. An unfortunate side
- effect of these schemes has been to make the use of IP addresses as
- identifiers associated with DNS (or any other) service somewhat
- problematic. Specifically, multiple dedicated DNS queries may not go
- to the same server even though sent to the same IP address. Non-DNS
- methods such as ICMP ping, TCP connections, or non-DNS UDP packets
- (such as those generated by tools like "traceroute"), etc., may well
- be even less certain to reach the same server as the one which
- receives the DNS queries.
-
- There is a well-known and frequently-used technique for determining
- an identity for a nameserver more specific than the possibly-non-
- unique "server that answered the query I sent to IP address A.B.C.D".
- The widespread use of the existing convention suggests a need for a
- documented, interoperable means of querying the identity of a
- nameserver that may be part of an anycast or load-balancing cluster.
- At the same time, however, it also has some drawbacks that argue
- against standardizing it as it's been practiced so far.
-
-2. Existing Conventions
-
- For some time, the commonly deployed Berkeley Internet Name Domain
- (BIND) implementation of the DNS protocol suite from the Internet
- Systems Consortium [BIND] has supported a way of identifying a
- particular server via the use of a standards-compliant, if somewhat
- unusual, DNS query. Specifically, a query to a recent BIND server
- for a TXT resource record in class 3 (CHAOS) for the domain name
- "HOSTNAME.BIND." will return a string that can be configured by the
- name server administrator to provide a unique identifier for the
- responding server. (The value defaults to the result of a
- gethostname() call). This mechanism, which is an extension of the
- BIND convention of using CHAOS class TXT RR queries to sub-domains of
- the "BIND." domain for version information, has been copied by
- several name server vendors.
-
- A refinement to the BIND-based mechanism, which dropped the
- implementation-specific label, replaces "BIND." with "SERVER.". Thus
- the query label to learn the unique name of a server may appear as
- "ID.SERVER.".
-
- (For reference, the other well-known name used by recent versions of
- BIND within the CHAOS class "BIND." domain is "VERSION.BIND.". A
- query for a CHAOS TXT RR for this name will return an
-
-
-
-Woolf & Conrad Informational [Page 2]
-\f
-RFC 4892 Serverid June 2007
-
-
- administratively defined string which defaults to the software
- version of the server responding. This is, however, not generally
- implemented by other vendors.)
-
-2.1. Advantages
-
- There are several valuable attributes to this mechanism, which
- account for its usefulness.
-
- 1. The "HOSTNAME.BIND." or "ID.SERVER." query response mechanism is
- within the DNS protocol itself. An identification mechanism that
- relies on the DNS protocol is more likely to be successful
- (although not guaranteed) in going to the same system as a
- "normal" DNS query.
-
- 2. Since the identity information is requested and returned within
- the DNS protocol, it doesn't require allowing any other query
- mechanism to the server, such as holes in firewalls for
- otherwise-unallowed ICMP Echo requests. Thus it is likely to
- reach the same server over a path subject to the same routing,
- resource, and security policy as the query, without any special
- exceptions to site security policy.
-
- 3. It is simple to configure. An administrator can easily turn on
- this feature and control the results of the relevant query.
-
- 4. It allows the administrator complete control of what information
- is given out in the response, minimizing passive leakage of
- implementation or configuration details. Such details are often
- considered sensitive by infrastructure operators.
-
-2.2. Disadvantages
-
- At the same time, there are some serious drawbacks to the CHAOS/TXT
- query mechanism that argue against standardizing it as it currently
- operates.
-
- 1. It requires an additional query to correlate between the answer
- to a DNS query under normal conditions and the supposed identity
- of the server receiving the query. There are a number of
- situations in which this simply isn't reliable.
-
- 2. It reserves an entire class in the DNS (CHAOS) for what amounts
- to one zone. While CHAOS class is defined in [RFC1034] and
- [RFC1035], it's not clear that supporting it solely for this
- purpose is a good use of the namespace or of implementation
- effort.
-
-
-
-
-Woolf & Conrad Informational [Page 3]
-\f
-RFC 4892 Serverid June 2007
-
-
- 3. The initial and still common form, using "BIND.", is
- implementation specific. BIND is one DNS implementation. At the
- time of this writing, it is probably most prevalent for
- authoritative servers. This does not justify standardizing on
- its ad hoc solution to a problem shared across many operators and
- implementors. Meanwhile, the aforementioned refinement changes
- the query label but preserves the ad hoc CHAOS/TXT mechanism.
-
- 4. There is no convention or shared understanding of what
- information an answer to such a query for a server identity could
- or should contain, including a possible encoding or
- authentication mechanism.
-
- 5. Hypothetically, since DNSSEC has been defined to cover all DNS
- classes, the TXT RRs returned in response to the "ID.SERVER."
- query could be signed, which has the advantages described in
- [RFC4033]. However, since DNSSEC deployment for the CHAOS class
- is neither existent nor foreseeable, and since the "ID.SERVER."
- TXT RR is expected to be unique per server, this would be
- impossible in practice.
-
- The first of the listed disadvantages may be technically the most
- serious. It argues for an attempt to design a good answer to the
- problem, "I need to know what nameserver is answering my queries",
- not simply a convenient one.
-
-3. Characteristics of an Implementation Neutral Convention
-
- The discussion above of advantages and disadvantages to the
- "HOSTNAME.BIND." mechanism suggest some requirements for a better
- solution to the server identification problem. These are summarized
- here as guidelines for any effort to provide appropriate protocol
- extensions:
-
- 1. The mechanism adopted must be in-band for the DNS protocol. That
- is, it needs to allow the query for the server's identifying
- information to be part of a normal, operational query. It should
- also permit a separate, dedicated query for the server's
- identifying information. But it should preserve the ability of
- the CHAOS/TXT query-based mechanism to work through firewalls and
- in other situations where only DNS can be relied upon to reach
- the server of interest.
-
- 2. The new mechanism should not require dedicated namespaces or
- other reserved values outside of the existing protocol mechanisms
- for these, i.e., the OPT pseudo-RR. In particular, it should not
- propagate the existing drawback of requiring support for a CLASS
-
-
-
-
-Woolf & Conrad Informational [Page 4]
-\f
-RFC 4892 Serverid June 2007
-
-
- and top level domain in the authoritative server (or the querying
- tool) to be useful.
-
- 3. Support for the identification functionality should be easy to
- implement and easy to enable. It must be easy to disable and
- should lend itself to access controls on who can query for it.
-
- 4. It should be possible to return a unique identifier for a server
- without requiring the exposure of information that may be non-
- public and considered sensitive by the operator, such as a
- hostname or unicast IP address maintained for administrative
- purposes.
-
- 5. It should be possible to authenticate the received data by some
- mechanism analogous to those provided by DNSSEC. In this
- context, the need could be met by including encryption options in
- the specification of a new mechanism.
-
- 6. The identification mechanism should not be implementation-
- specific.
-
-4. IANA Considerations
-
- This document proposes no specific IANA action. Protocol extensions,
- if any, to meet the requirements described are out of scope for this
- document. A proposed extension, specified and adopted by normal IETF
- process, is described in [NSID], including relevant IANA action.
-
-5. Security Considerations
-
- Providing identifying information as to which server is responding to
- a particular query from a particular location in the Internet can be
- seen as information leakage and thus a security risk. This motivates
- the suggestion above that a new mechanism for server identification
- allow the administrator to disable the functionality altogether or
- partially restrict availability of the data. It also suggests that
- the server identification data should not be readily correlated with
- a hostname or unicast IP address that may be considered private to
- the nameserver operator's management infrastructure.
-
- Propagation of protocol or service meta-data can sometimes expose the
- application to denial of service or other attack. As the DNS is a
- critically important infrastructure service for the production
- Internet, extra care needs to be taken against this risk for
- designers, implementors, and operators of a new mechanism for server
- identification.
-
-
-
-
-
-Woolf & Conrad Informational [Page 5]
-\f
-RFC 4892 Serverid June 2007
-
-
- Both authentication and confidentiality of server identification data
- are potentially of interest to administrators -- that is, operators
- may wish to make such data available and reliable to themselves and
- their chosen associates only. This constraint would imply both an
- ability to authenticate it to themselves and to keep it private from
- arbitrary other parties, which leads to characteristics 4 and 5 of an
- improved solution.
-
-6. Acknowledgements
-
- The technique for host identification documented here was initially
- implemented by Paul Vixie of the Internet Software Consortium in the
- Berkeley Internet Name Daemon package. Comments and questions on
- earlier versions were provided by Bob Halley, Brian Wellington,
- Andreas Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and
- members of the ICANN Root Server System Advisory Committee. The
- newest version takes a significantly different direction from
- previous versions, owing to discussion among contributors to the
- DNSOP working group and others, particularly Olafur Gudmundsson, Ed
- Lewis, Bill Manning, Sam Weiler, and Rob Austein.
-
-7. References
-
-7.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
- Shared Unicast Addresses", RFC 3258, April 2002.
-
-7.2. Informative References
-
- [BIND] ISC, "BIND 9 Configuration Reference".
-
- [NSID] Austein, R., "DNS Name Server Identifier Option (NSID)",
- Work in Progress, June 2006.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC
- 4033, March 2005.
-
-
-
-
-
-
-
-Woolf & Conrad Informational [Page 6]
-\f
-RFC 4892 Serverid June 2007
-
-
-Authors' Addresses
-
- Suzanne Woolf
- Internet Systems Consortium, Inc.
- 950 Charter Street
- Redwood City, CA 94063
- US
-
- Phone: +1 650 423-1333
- EMail: woolf@isc.org
- URI: http://www.isc.org/
-
-
- David Conrad
- ICANN
- 4676 Admiralty Way
- Marina del Rey, CA 90292
- US
-
- Phone: +1 310 823 9358
- EMail: david.conrad@icann.org
- URI: http://www.iana.org/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad Informational [Page 7]
-\f
-RFC 4892 Serverid June 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Woolf & Conrad Informational [Page 8]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group M. StJohns
-Request for Comments: 5011 Independent
-Category: Standards Track September 2007
-
-
- Automated Updates of DNS Security (DNSSEC) Trust Anchors
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- This document describes a means for automated, authenticated, and
- authorized updating of DNSSEC "trust anchors". The method provides
- protection against N-1 key compromises of N keys in the trust point
- key set. Based on the trust established by the presence of a current
- anchor, other anchors may be added at the same place in the
- hierarchy, and, ultimately, supplant the existing anchor(s).
-
- This mechanism will require changes to resolver management behavior
- (but not resolver resolution behavior), and the addition of a single
- flag bit to the DNSKEY record.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Standards Track [Page 1]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
-Table of Contents
-
- 1. Introduction ....................................................2
- 1.1. Compliance Nomenclature ....................................3
- 2. Theory of Operation .............................................3
- 2.1. Revocation .................................................4
- 2.2. Add Hold-Down ..............................................4
- 2.3. Active Refresh .............................................5
- 2.4. Resolver Parameters ........................................6
- 2.4.1. Add Hold-Down Time ..................................6
- 2.4.2. Remove Hold-Down Time ...............................6
- 2.4.3. Minimum Trust Anchors per Trust Point ...............6
- 3. Changes to DNSKEY RDATA Wire Format .............................6
- 4. State Table .....................................................6
- 4.1. Events .....................................................7
- 4.2. States .....................................................7
- 5. Trust Point Deletion ............................................8
- 6. Scenarios - Informative .........................................9
- 6.1. Adding a Trust Anchor ......................................9
- 6.2. Deleting a Trust Anchor ....................................9
- 6.3. Key Roll-Over .............................................10
- 6.4. Active Key Compromised ....................................10
- 6.5. Stand-by Key Compromised ..................................10
- 6.6. Trust Point Deletion ......................................10
- 7. IANA Considerations ............................................11
- 8. Security Considerations ........................................11
- 8.1. Key Ownership vs. Acceptance Policy .......................11
- 8.2. Multiple Key Compromise ...................................12
- 8.3. Dynamic Updates ...........................................12
- 9. Normative References ...........................................12
- 10. Informative References ........................................12
-
-1. Introduction
-
- As part of the reality of fielding DNSSEC (Domain Name System
- Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
- come to the realization that there will not be one signed name space,
- but rather islands of signed name spaces each originating from
- specific points (i.e., 'trust points') in the DNS tree. Each of
- those islands will be identified by the trust point name, and
- validated by at least one associated public key. For the purpose of
- this document, we'll call the association of that name and a
- particular key a 'trust anchor'. A particular trust point can have
- more than one key designated as a trust anchor.
-
- For a DNSSEC-aware resolver to validate information in a DNSSEC
- protected branch of the hierarchy, it must have knowledge of a trust
- anchor applicable to that branch. It may also have more than one
-
-
-
-StJohns Standards Track [Page 2]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
- trust anchor for any given trust point. Under current rules, a chain
- of trust for DNSSEC-protected data that chains its way back to ANY
- known trust anchor is considered 'secure'.
-
- Because of the probable balkanization of the DNSSEC tree due to
- signing voids at key locations, a resolver may need to know literally
- thousands of trust anchors to perform its duties (e.g., consider an
- unsigned ".COM"). Requiring the owner of the resolver to manually
- manage these many relationships is problematic. It's even more
- problematic when considering the eventual requirement for key
- replacement/update for a given trust anchor. The mechanism described
- herein won't help with the initial configuration of the trust anchors
- in the resolvers, but should make trust point key
- replacement/rollover more viable.
-
- As mentioned above, this document describes a mechanism whereby a
- resolver can update the trust anchors for a given trust point, mainly
- without human intervention at the resolver. There are some corner
- cases discussed (e.g., multiple key compromise) that may require
- manual intervention, but they should be few and far between. This
- document DOES NOT discuss the general problem of the initial
- configuration of trust anchors for the resolver.
-
-1.1. Compliance Nomenclature
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14, [RFC2119].
-
-2. Theory of Operation
-
- The general concept of this mechanism is that existing trust anchors
- can be used to authenticate new trust anchors at the same point in
- the DNS hierarchy. When a zone operator adds a new SEP key (i.e., a
- DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section
- 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
- validated by an existing trust anchor, then the resolver can add the
- new key to its set of valid trust anchors for that trust point.
-
- There are some issues with this approach that need to be mitigated.
- For example, a compromise of one of the existing keys could allow an
- attacker to add their own 'valid' data. This implies a need for a
- method to revoke an existing key regardless of whether or not that
- key is compromised. As another example, assuming a single key
- compromise, we need to prevent an attacker from adding a new key and
- revoking all the other old keys.
-
-
-
-
-
-StJohns Standards Track [Page 3]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
-2.1. Revocation
-
- Assume two trust anchor keys A and B. Assume that B has been
- compromised. Without a specific revocation bit, B could invalidate A
- simply by sending out a signed trust point key set that didn't
- contain A. To fix this, we add a mechanism that requires knowledge
- of the private key of a DNSKEY to revoke that DNSKEY.
-
- A key is considered revoked when the resolver sees the key in a
- self-signed RRSet and the key has the REVOKE bit (see Section 7
- below) set to '1'. Once the resolver sees the REVOKE bit, it MUST
- NOT use this key as a trust anchor or for any other purpose except to
- validate the RRSIG it signed over the DNSKEY RRSet specifically for
- the purpose of validating the revocation. Unlike the 'Add' operation
- below, revocation is immediate and permanent upon receipt of a valid
- revocation at the resolver.
-
- A self-signed RRSet is a DNSKEY RRSet that contains the specific
- DNSKEY and for which there is a corresponding validated RRSIG record.
- It's not a special DNSKEY RRSet, just a way of describing the
- validation requirements for that RRSet.
-
- N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint
- than one without the bit set. This affects the matching of a DNSKEY
- to DS records in the parent [RFC3755], or the fingerprint stored at a
- resolver used to configure a trust point.
-
- In the given example, the attacker could revoke B because it has
- knowledge of B's private key, but could not revoke A.
-
-2.2. Add Hold-Down
-
- Assume two trust point keys A and B. Assume that B has been
- compromised. An attacker could generate and add a new trust anchor
- key C (by adding C to the DNSKEY RRSet and signing it with B), and
- then invalidate the compromised key. This would result in both the
- attacker and owner being able to sign data in the zone and have it
- accepted as valid by resolvers.
-
- To mitigate but not completely solve this problem, we add a hold-down
- time to the addition of the trust anchor. When the resolver sees a
- new SEP key in a validated trust point DNSKEY RRSet, the resolver
- starts an acceptance timer, and remembers all the keys that validated
- the RRSet. If the resolver ever sees the DNSKEY RRSet without the
- new key but validly signed, it stops the acceptance process for that
- key and resets the acceptance timer. If all of the keys that were
-
-
-
-
-
-StJohns Standards Track [Page 4]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
- originally used to validate this key are revoked prior to the timer
- expiring, the resolver stops the acceptance process and resets the
- timer.
-
- Once the timer expires, the new key will be added as a trust anchor
- the next time the validated RRSet with the new key is seen at the
- resolver. The resolver MUST NOT treat the new key as a trust anchor
- until the hold-down time expires AND it has retrieved and validated a
- DNSKEY RRSet after the hold-down time that contains the new key.
-
- N.B.: Once the resolver has accepted a key as a trust anchor, the key
- MUST be considered a valid trust anchor by that resolver until
- explicitly revoked as described above.
-
- In the given example, the zone owner can recover from a compromise by
- revoking B and adding a new key D and signing the DNSKEY RRSet with
- both A and B.
-
- The reason this does not completely solve the problem has to do with
- the distributed nature of DNS. The resolver only knows what it sees.
- A determined attacker who holds one compromised key could keep a
- single resolver from realizing that the key had been compromised by
- intercepting 'real' data from the originating zone and substituting
- their own (e.g., using the example, signed only by B). This is no
- worse than the current situation assuming a compromised key.
-
-2.3. Active Refresh
-
- A resolver that has been configured for an automatic update of keys
- from a particular trust point MUST query that trust point (e.g., do a
- lookup for the DNSKEY RRSet and related RRSIG records) no less often
- than the lesser of 15 days, half the original TTL for the DNSKEY
- RRSet, or half the RRSIG expiration interval and no more often than
- once per hour. The expiration interval is the amount of time from
- when the RRSIG was last retrieved until the expiration time in the
- RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
- 1/2*RRSigExpirationInterval))
-
- If the query fails, the resolver MUST repeat the query until
- satisfied no more often than once an hour and no less often than the
- lesser of 1 day, 10% of the original TTL, or 10% of the original
- expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day,
- .1 * origTTL, .1 * expireInterval)).
-
-
-
-
-
-
-
-
-StJohns Standards Track [Page 5]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
-2.4. Resolver Parameters
-
-2.4.1. Add Hold-Down Time
-
- The add hold-down time is 30 days or the expiration time of the
- original TTL of the first trust point DNSKEY RRSet that contained the
- new key, whichever is greater. This ensures that at least two
- validated DNSKEY RRSets that contain the new key MUST be seen by the
- resolver prior to the key's acceptance.
-
-2.4.2. Remove Hold-Down Time
-
- The remove hold-down time is 30 days. This parameter is solely a key
- management database bookeeping parameter. Failure to remove
- information about the state of defunct keys from the database will
- not adversely impact the security of this protocol, but may end up
- with a database cluttered with obsolete key information.
-
-2.4.3. Minimum Trust Anchors per Trust Point
-
- A compliant resolver MUST be able to manage at least five SEP keys
- per trust point.
-
-3. Changes to DNSKEY RDATA Wire Format
-
- Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag.
- If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
- signed by the associated key, then the resolver MUST consider this
- key permanently invalid for all purposes except for validating the
- revocation.
-
-4. State Table
-
- The most important thing to understand is the resolver's view of any
- key at a trust point. The following state table describes this view
- at various points in the key's lifetime. The table is a normative
- part of this specification. The initial state of the key is 'Start'.
- The resolver's view of the state of the key changes as various events
- occur.
-
- This is the state of a trust-point key as seen from the resolver.
- The column on the left indicates the current state. The header at
- the top shows the next state. The intersection of the two shows the
- event that will cause the state to transition from the current state
- to the next.
-
-
-
-
-
-
-StJohns Standards Track [Page 6]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
- NEXT STATE
- --------------------------------------------------
- FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
- ----------------------------------------------------------
- Start | |NewKey | | | | |
- ----------------------------------------------------------
- AddPend |KeyRem | |AddTime| | | |
- ----------------------------------------------------------
- Valid | | | |KeyRem |Revbit | |
- ----------------------------------------------------------
- Missing | | |KeyPres| |Revbit | |
- ----------------------------------------------------------
- Revoked | | | | | |RemTime|
- ----------------------------------------------------------
- Removed | | | | | | |
- ----------------------------------------------------------
-
- State Table
-
-4.1. Events
-
- NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
- That key will become a new trust anchor for the named trust
- point after it's been present in the RRSet for at least 'add
- time'.
-
- KeyPres The key has returned to the valid DNSKEY RRSet.
-
- KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
- this key.
-
- AddTime The key has been in every valid DNSKEY RRSet seen for at
- least the 'add time'.
-
- RemTime A revoked key has been missing from the trust-point DNSKEY
- RRSet for sufficient time to be removed from the trust set.
-
- RevBit The key has appeared in the trust anchor DNSKEY RRSet with
- its "REVOKED" bit set, and there is an RRSig over the DNSKEY
- RRSet signed by this key.
-
-4.2. States
-
- Start The key doesn't yet exist as a trust anchor at the resolver.
- It may or may not exist at the zone server, but either
- hasn't yet been seen at the resolver or was seen but was
- absent from the last DNSKEY RRSet (e.g., KeyRem event).
-
-
-
-
-StJohns Standards Track [Page 7]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
- AddPend The key has been seen at the resolver, has its 'SEP' bit
- set, and has been included in a validated DNSKEY RRSet.
- There is a hold-down time for the key before it can be used
- as a trust anchor.
-
- Valid The key has been seen at the resolver and has been included
- in all validated DNSKEY RRSets from the time it was first
- seen through the hold-down time. It is now valid for
- verifying RRSets that arrive after the hold-down time.
- Clarification: The DNSKEY RRSet does not need to be
- continuously present at the resolver (e.g., its TTL might
- expire). If the RRSet is seen and is validated (i.e.,
- verifies against an existing trust anchor), this key MUST be
- in the RRSet, otherwise a 'KeyRem' event is triggered.
-
- Missing This is an abnormal state. The key remains a valid trust-
- point key, but was not seen at the resolver in the last
- validated DNSKEY RRSet. This is an abnormal state because
- the zone operator should be using the REVOKE bit prior to
- removal.
-
- Revoked This is the state a key moves to once the resolver sees an
- RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet
- contains this key with its REVOKE bit set to '1'. Once in
- this state, this key MUST permanently be considered invalid
- as a trust anchor.
-
- Removed After a fairly long hold-down time, information about this
- key may be purged from the resolver. A key in the removed
- state MUST NOT be considered a valid trust anchor. (Note:
- this state is more or less equivalent to the "Start" state,
- except that it's bad practice to re-introduce previously
- used keys -- think of this as the holding state for all the
- old keys for which the resolver no longer needs to track
- state.)
-
-5. Trust Point Deletion
-
- A trust point that has all of its trust anchors revoked is considered
- deleted and is treated as if the trust point was never configured.
- If there are no superior configured trust points, data at and below
- the deleted trust point are considered insecure by the resolver. If
- there ARE superior configured trust points, data at and below the
- deleted trust point are evaluated with respect to the superior trust
- point(s).
-
- Alternately, a trust point that is subordinate to another configured
- trust point MAY be deleted by a resolver after 180 days, where such a
-
-
-
-StJohns Standards Track [Page 8]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
- subordinate trust point validly chains to a superior trust point.
- The decision to delete the subordinate trust anchor is a local
- configuration decision. Once the subordinate trust point is deleted,
- validation of the subordinate zone is dependent on validating the
- chain of trust to the superior trust point.
-
-6. Scenarios - Informative
-
- The suggested model for operation is to have one active key and one
- stand-by key at each trust point. The active key will be used to
- sign the DNSKEY RRSet. The stand-by key will not normally sign this
- RRSet, but the resolver will accept it as a trust anchor if/when it
- sees the signature on the trust point DNSKEY RRSet.
-
- Since the stand-by key is not in active signing use, the associated
- private key may (and should) be provided with additional protections
- not normally available to a key that must be used frequently (e.g.,
- locked in a safe, split among many parties, etc). Notionally, the
- stand-by key should be less subject to compromise than an active key,
- but that will be dependent on operational concerns not addressed
- here.
-
-6.1. Adding a Trust Anchor
-
- Assume an existing trust anchor key 'A'.
-
- 1. Generate a new key pair.
-
- 2. Create a DNSKEY record from the key pair and set the SEP and Zone
- Key bits.
-
- 3. Add the DNSKEY to the RRSet.
-
- 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
- 'A'.
-
- 5. Wait for various resolvers' timers to go off and for them to
- retrieve the new DNSKEY RRSet and signatures.
-
- 6. The new trust anchor will be populated at the resolvers on the
- schedule described by the state table and update algorithm -- see
- Sections 2 and 4 above.
-
-6.2. Deleting a Trust Anchor
-
- Assume existing trust anchors 'A' and 'B' and that you want to revoke
- and delete 'A'.
-
-
-
-
-StJohns Standards Track [Page 9]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
- 1. Set the revocation bit on key 'A'.
-
- 2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked.
- The operator should include the revoked 'A' in the RRSet for at
- least the remove hold-down time, but then may remove it from the
- DNSKEY RRSet.
-
-6.3. Key Roll-Over
-
- Assume existing keys A and B. 'A' is actively in use (i.e. has been
- signing the DNSKEY RRSet). 'B' was the stand-by key. (i.e. has been
- in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
- used to sign the RRSet).
-
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'A'.
- 4. Sign the RRSet with 'A' and 'B'.
-
- 'A' is now revoked, 'B' is now the active key, and 'C' will be the
- stand-by key once the hold-down expires. The operator should include
- the revoked 'A' in the RRSet for at least the remove hold-down time,
- but may then remove it from the DNSKEY RRSet.
-
-6.4. Active Key Compromised
-
- This is the same as the mechanism for Key Roll-Over (Section 6.3)
- above, assuming 'A' is the active key.
-
-6.5. Stand-by Key Compromised
-
- Using the same assumptions and naming conventions as Key Roll-Over
- (Section 6.3) above:
-
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'B'.
- 4. Sign the RRSet with 'A' and 'B'.
-
- 'B' is now revoked, 'A' remains the active key, and 'C' will be the
- stand-by key once the hold-down expires. 'B' should continue to be
- included in the RRSet for the remove hold-down time.
-
-6.6. Trust Point Deletion
-
- To delete a trust point that is subordinate to another configured
- trust point (e.g., example.com to .com) requires some juggling of the
- data. The specific process is:
-
-
-
-StJohns Standards Track [Page 10]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
- 1. Generate a new DNSKEY and DS record and provide the DS record to
- the parent along with DS records for the old keys.
-
- 2. Once the parent has published the DSs, add the new DNSKEY to the
- RRSet and revoke ALL of the old keys at the same time, while
- signing the DNSKEY RRSet with all of the old and new keys.
-
- 3. After 30 days, stop publishing the old, revoked keys and remove
- any corresponding DS records in the parent.
-
- Revoking the old trust-point keys at the same time as adding new keys
- that chain to a superior trust prevents the resolver from adding the
- new keys as trust anchors. Adding DS records for the old keys avoids
- a race condition where either the subordinate zone becomes unsecure
- (because the trust point was deleted) or becomes bogus (because it
- didn't chain to the superior zone).
-
-7. IANA Considerations
-
- The IANA has assigned a bit in the DNSKEY flags field (see Section 7
- of [RFC4034]) for the REVOKE bit (8).
-
-8. Security Considerations
-
- In addition to the following sections, see also Theory of Operation
- above (Section 2) and especially Section 2.2 for related discussions.
-
- Security considerations for trust anchor rollover not specific to
- this protocol are discussed in [RFC4986].
-
-8.1. Key Ownership vs. Acceptance Policy
-
- The reader should note that, while the zone owner is responsible for
- creating and distributing keys, it's wholly the decision of the
- resolver owner as to whether to accept such keys for the
- authentication of the zone information. This implies the decision to
- update trust-anchor keys based on trusting a current trust-anchor key
- is also the resolver owner's decision.
-
- The resolver owner (and resolver implementers) MAY choose to permit
- or prevent key status updates based on this mechanism for specific
- trust points. If they choose to prevent the automated updates, they
- will need to establish a mechanism for manual or other out-of-band
- updates, which are outside the scope of this document.
-
-
-
-
-
-
-
-StJohns Standards Track [Page 11]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
-8.2. Multiple Key Compromise
-
- This scheme permits recovery as long as at least one valid trust-
- anchor key remains uncompromised, e.g., if there are three keys, you
- can recover if two of them are compromised. The zone owner should
- determine their own level of comfort with respect to the number of
- active, valid trust anchors in a zone and should be prepared to
- implement recovery procedures once they detect a compromise. A
- manual or other out-of-band update of all resolvers will be required
- if all trust-anchor keys at a trust point are compromised.
-
-8.3. Dynamic Updates
-
- Allowing a resolver to update its trust anchor set based on in-band
- key information is potentially less secure than a manual process.
- However, given the nature of the DNS, the number of resolvers that
- would require update if a trust anchor key were compromised, and the
- lack of a standard management framework for DNS, this approach is no
- worse than the existing situation.
-
-9. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer (DS)", RFC 3755, May 2004.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC
- 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-10. Informative References
-
- [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
- "Requirements Related to DNS Security (DNSSEC) Trust
- Anchor Rollover", RFC 4986, August 2007.
-
-
-
-
-
-
-StJohns Standards Track [Page 12]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
-Author's Address
-
- Michael StJohns
- Independent
-
- EMail: mstjohns@comcast.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Standards Track [Page 13]
-\f
-RFC 5011 Trust Anchor Update September 2007
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2007).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Standards Track [Page 14]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group J. Jansen
-Request for Comments: 5702 NLnet Labs
-Category: Standards Track October 2009
-
-
- Use of SHA-2 Algorithms with RSA in
- DNSKEY and RRSIG Resource Records for DNSSEC
-
-Abstract
-
- This document describes how to produce RSA/SHA-256 and RSA/SHA-512
- DNSKEY and RRSIG resource records for use in the Domain Name System
- Security Extensions (RFC 4033, RFC 4034, and RFC 4035).
-
-Status of This Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document. Code Components extracted from this document must
- include Simplified BSD License text as described in Section 4.e of
- the Trust Legal Provisions and are provided without warranty as
- described in the BSD License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen Standards Track [Page 1]
-\f
-RFC 5702 DNSSEC RSA/SHA-2 October 2009
-
-
-Table of Contents
-
- 1. Introduction ....................................................2
- 2. DNSKEY Resource Records .........................................3
- 2.1. RSA/SHA-256 DNSKEY Resource Records ........................3
- 2.2. RSA/SHA-512 DNSKEY Resource Records ........................3
- 3. RRSIG Resource Records ..........................................3
- 3.1. RSA/SHA-256 RRSIG Resource Records .........................4
- 3.2. RSA/SHA-512 RRSIG Resource Records .........................4
- 4. Deployment Considerations .......................................5
- 4.1. Key Sizes ..................................................5
- 4.2. Signature Sizes ............................................5
- 5. Implementation Considerations ...................................5
- 5.1. Support for SHA-2 Signatures ...............................5
- 5.2. Support for NSEC3 Denial of Existence ......................5
- 6. Examples ........................................................6
- 6.1. RSA/SHA-256 Key and Signature ..............................6
- 6.2. RSA/SHA-512 Key and Signature ..............................7
- 7. IANA Considerations .............................................8
- 8. Security Considerations .........................................8
- 8.1. SHA-1 versus SHA-2 Considerations for RRSIG
- Resource Records ...........................................8
- 8.2. Signature Type Downgrade Attacks ...........................8
- 9. Acknowledgments .................................................9
- 10. References .....................................................9
- 10.1. Normative References ......................................9
- 10.2. Informative References ....................................9
-
-1. Introduction
-
- The Domain Name System (DNS) is the global, hierarchical distributed
- database for Internet Naming. The DNS has been extended to use
- cryptographic keys and digital signatures for the verification of the
- authenticity and integrity of its data. [RFC4033], [RFC4034], and
- [RFC4035] describe these DNS Security Extensions, called DNSSEC.
-
- RFC 4034 describes how to store DNSKEY and RRSIG resource records,
- and specifies a list of cryptographic algorithms to use. This
- document extends that list with the algorithms RSA/SHA-256 and RSA/
- SHA-512, and specifies how to store DNSKEY data and how to produce
- RRSIG resource records with these hash algorithms.
-
- Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family
- of algorithms is assumed in this document.
-
-
-
-
-
-
-
-Jansen Standards Track [Page 2]
-\f
-RFC 5702 DNSSEC RSA/SHA-2 October 2009
-
-
- To refer to both SHA-256 and SHA-512, this document will use the name
- SHA-2. This is done to improve readability. When a part of text is
- specific for either SHA-256 or SHA-512, their specific names are
- used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be
- grouped using the name RSA/SHA-2.
-
- The term "SHA-2" is not officially defined but is usually used to
- refer to the collection of the algorithms SHA-224, SHA-256, SHA-384,
- and SHA-512. Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2
- will only refer to SHA-256 and SHA-512 in this document.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-2. DNSKEY Resource Records
-
- The format of the DNSKEY RR can be found in [RFC4034]. [RFC3110]
- describes the use of RSA/SHA-1 for DNSSEC signatures.
-
-2.1. RSA/SHA-256 DNSKEY Resource Records
-
- RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
- resource records (RRs) with the algorithm number 8.
-
- For interoperability, as in [RFC3110], the key size of RSA/SHA-256
- keys MUST NOT be less than 512 bits and MUST NOT be more than 4096
- bits.
-
-2.2. RSA/SHA-512 DNSKEY Resource Records
-
- RSA public keys for use with RSA/SHA-512 are stored in DNSKEY
- resource records (RRs) with the algorithm number 10.
-
- The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and
- MUST NOT be more than 4096 bits.
-
-3. RRSIG Resource Records
-
- The value of the signature field in the RRSIG RR follows the RSASSA-
- PKCS1-v1_5 signature scheme and is calculated as follows. The values
- for the RDATA fields that precede the signature data are specified in
- [RFC4034].
-
-
-
-
-
-
-
-
-Jansen Standards Track [Page 3]
-\f
-RFC 5702 DNSSEC RSA/SHA-2 October 2009
-
-
- hash = SHA-XXX(data)
-
- Here XXX is either 256 or 512, depending on the algorithm used, as
- specified in FIPS PUB 180-3; "data" is the wire format data of the
- resource record set that is signed, as specified in [RFC4034].
-
- signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
- Here "|" is concatenation; "00", "01", "FF", and "00" are fixed
- octets of corresponding hexadecimal value; "e" is the private
- exponent of the signing RSA key; and "n" is the public modulus of the
- signing key. The FF octet MUST be repeated the exact number of times
- so that the total length of the concatenated term in parentheses
- equals the length of the modulus of the signer's public key ("n").
-
- The "prefix" is intended to make the use of standard cryptographic
- libraries easier. These specifications are taken directly from the
- specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of
- [RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2
- of [RFC3447]). The prefixes for the different algorithms are
- specified below.
-
-3.1. RSA/SHA-256 RRSIG Resource Records
-
- RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
- records (RRs) with algorithm number 8.
-
- The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as
- specified in PKCS #1 v2.1 [RFC3447]:
-
- hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
-
-3.2. RSA/SHA-512 RRSIG Resource Records
-
- RSA/SHA-512 signatures are stored in the DNS using RRSIG resource
- records (RRs) with algorithm number 10.
-
- The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as
- specified in PKCS #1 v2.1 [RFC3447]:
-
- hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
-
-
-
-
-
-
-
-
-
-
-Jansen Standards Track [Page 4]
-\f
-RFC 5702 DNSSEC RSA/SHA-2 October 2009
-
-
-4. Deployment Considerations
-
-4.1. Key Sizes
-
- Apart from the restrictions in Section 2, this document will not
- specify what size of keys to use. That is an operational issue and
- depends largely on the environment and intended use. A good starting
- point for more information would be NIST SP 800-57 [NIST800-57].
-
-4.2. Signature Sizes
-
- In this family of signing algorithms, the size of signatures is
- related to the size of the key and not to the hashing algorithm used
- in the signing process. Therefore, RRSIG resource records produced
- with RSA/SHA-256 or RSA/SHA-512 will have the same size as those
- produced with RSA/SHA-1, if the keys have the same length.
-
-5. Implementation Considerations
-
-5.1. Support for SHA-2 Signatures
-
- DNSSEC-aware implementations SHOULD be able to support RRSIG and
- DNSKEY resource records created with the RSA/SHA-2 algorithms as
- defined in this document.
-
-5.2. Support for NSEC3 Denial of Existence
-
- [RFC5155] defines new algorithm identifiers for existing signing
- algorithms, to indicate that zones signed with these algorithm
- identifiers can use NSEC3 as well as NSEC records to provide denial
- of existence. That mechanism was chosen to protect implementations
- predating RFC 5155 from encountering resource records about which
- they could not know. This document does not define such algorithm
- aliases.
-
- A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate
- negative answers in the form of both NSEC and NSEC3 with hash
- algorithm 1, as defined in [RFC5155]. An authoritative server that
- does not implement NSEC3 MAY still serve zones that use RSA/SHA-2
- with NSEC denial of existence.
-
-
-
-
-
-
-
-
-
-
-
-Jansen Standards Track [Page 5]
-\f
-RFC 5702 DNSSEC RSA/SHA-2 October 2009
-
-
-6. Examples
-
-6.1. RSA/SHA-256 Key and Signature
-
- Given a private key with the following values (in Base64):
-
- Private-key-format: v1.2
- Algorithm: 8 (RSASHA256)
- Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm
- idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q==
- PublicExponent: AQAB
- PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/
- HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ==
- Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk=
- Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE=
- Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk=
- Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE=
- Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q=
-
- The DNSKEY record for this key would be:
-
- example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI
- my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P
- kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b}
-
- With this key, sign the following RRSet, consisting of 1 A record:
-
- www.example.net. 3600 IN A 192.0.2.91
-
- If the inception date is set at 00:00 hours on January 1st, 2000, and
- the expiration date at 00:00 hours on January 1st, 2030, the
- following signature should be created:
-
- www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000
- 20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9
- l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa
- cFYK/lPtPiVYP4bwg==);{id = 9033}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen Standards Track [Page 6]
-\f
-RFC 5702 DNSSEC RSA/SHA-2 October 2009
-
-
-6.2. RSA/SHA-512 Key and Signature
-
- Given a private key with the following values (in Base64):
-
- Private-key-format: v1.2
- Algorithm: 10 (RSASHA512)
- Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf
- Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk
- 8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V
- jXZlNKdyit99waaE4s=
- PublicExponent: AQAB
- PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6
- AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj
- yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3
- SEIAsrB043XzGrKIVE=
- Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x
- nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ==
- Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK
- Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw==
- Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM
- MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q==
- Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J
- PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w==
- Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q
- /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ==
-
- The DNSKEY record for this key would be:
-
- example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD
- p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD
- xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g
- pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL
- );{id = 3740 (zsk), size = 1024b}
-
- With this key, sign the following RRSet, consisting of 1 A record:
-
- www.example.net. 3600 IN A 192.0.2.91
-
- If the inception date is set at 00:00 hours on January 1st, 2000, and
- the expiration date at 00:00 hours on January 1st, 2030, the
- following signature should be created:
-
- www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000
- 20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t
- 6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa
- eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL
- DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw
- =);{id = 3740}
-
-
-
-Jansen Standards Track [Page 7]
-\f
-RFC 5702 DNSSEC RSA/SHA-2 October 2009
-
-
-7. IANA Considerations
-
- This document updates the IANA registry "DNS SECURITY ALGORITHM
- NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols). The
- following entries are added to the registry:
-
- Zone Trans.
- Value Description Mnemonic Signing Sec. References
- 8 RSA/SHA-256 RSASHA256 Y * RFC 5702
- 10 RSA/SHA-512 RSASHA512 Y * RFC 5702
-
- * There has been no determination of standardization of the use of
- this algorithm with Transaction Security.
-
-8. Security Considerations
-
-8.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records
-
- Users of DNSSEC are encouraged to deploy SHA-2 as soon as software
- implementations allow for it. SHA-2 is widely believed to be more
- resilient to attack than SHA-1, and confidence in SHA-1's strength is
- being eroded by recently announced attacks. Regardless of whether or
- not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
- time of this writing) that SHA-2 is the better choice for use in
- DNSSEC records.
-
- SHA-2 is considered sufficiently strong for the immediate future, but
- predictions about future development in cryptography and
- cryptanalysis are beyond the scope of this document.
-
- The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one
- used for RSA/SHA-1 signatures. This should ease implementation of
- the new hashing algorithms in DNSSEC software.
-
-8.2. Signature Type Downgrade Attacks
-
- Since each RRSet MUST be signed with each algorithm present in the
- DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a
- malicious party cannot filter out the RSA/SHA-2 RRSIG and force the
- validator to use the RSA/SHA-1 signature if both are present in the
- zone. This should provide resilience against algorithm downgrade
- attacks, if the validator supports RSA/SHA-2.
-
-
-
-
-
-
-
-
-
-Jansen Standards Track [Page 8]
-\f
-RFC 5702 DNSSEC RSA/SHA-2 October 2009
-
-
-9. Acknowledgments
-
- This document is a minor extension to [RFC4034]. Also, we try to
- follow the documents [RFC3110] and [RFC4509] for consistency. The
- authors of and contributors to these documents are gratefully
- acknowledged for their hard work.
-
- The following people provided additional feedback and text: Jaap
- Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont,
- Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose,
- Michael St. Johns, and Wouter Wijngaards.
-
-10. References
-
-10.1. Normative References
-
- [FIPS.180-3.2008]
- National Institute of Standards and Technology, "Secure
- Hash Standard", FIPS PUB 180-3, October 2008.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
- Name System (DNS)", RFC 3110, May 2001.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-10.2. Informative References
-
- [NIST800-57]
- Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
- "Recommendations for Key Management", NIST SP 800-57,
- March 2007.
-
- [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
- Standards (PKCS) #1: RSA Cryptography Specifications
- Version 2.1", RFC 3447, February 2003.
-
-
-
-Jansen Standards Track [Page 9]
-\f
-RFC 5702 DNSSEC RSA/SHA-2 October 2009
-
-
- [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-Author's Address
-
- Jelte Jansen
- NLnet Labs
- Science Park 140
- 1098 XG Amsterdam
- NL
-
- EMail: jelte@NLnetLabs.nl
- URI: http://www.nlnetlabs.nl/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen Standards Track [Page 10]
-\f
projects / thirdparty / bind9.git / commitdiff
