Compare commits
1 Commits
v9.4-ESV-R
...
v9.4-ESVb1
| Author | SHA1 | Date | |
|---|---|---|---|
|
e414d1aa9a |
@@ -1,370 +0,0 @@
|
||||
DNS Extensions working group V.Dolmatov, Ed.
|
||||
Internet-Draft Cryptocom Ltd.
|
||||
Intended status: Standards Track April 8, 2009
|
||||
Expires: December 31, 2009
|
||||
|
||||
|
||||
Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
|
||||
for DNSSEC
|
||||
draft-dolmatov-dnsext-dnssec-gost-00
|
||||
|
||||
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 31 December 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 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 describes how to produce GOST signature and hash algorithms
|
||||
DNSKEY and RRSIG resource records for use in the Domain Name System
|
||||
Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
|
||||
2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . .
|
||||
2.1. Using a public key with existing cryptographic libraries. .
|
||||
2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . .
|
||||
3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . .
|
||||
4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . .
|
||||
5. NSEC3 Resource Records . . . . . . . . . . . . . . . . . . . .
|
||||
6. Deployment Considerations . . . . . . . . . . . . . . . . . . .
|
||||
6.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . .
|
||||
6.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . .
|
||||
6.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . .
|
||||
7. Implementation Considerations . . . . . . . . . . . . . . . . .
|
||||
7.1. Support for GOST signatures . . . . . . . . . . . . . . . .
|
||||
7.2. Support for NSEC3 Denial of Existence . . . . . . . . . . .
|
||||
7.2.1. NSEC3 in Authoritative servers . . . . . . . . . . . .
|
||||
7.2.2. NSEC3 in Validators . . . . . . . . . . . . . . . . . .
|
||||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .
|
||||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .
|
||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . .
|
||||
10.1. Normative References . . . . . . . . . . . . . . . . . . .
|
||||
10.2. Informative References . . . . . . . . . . . . . . . . . .
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .
|
||||
|
||||
|
||||
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. RFC 4033 [RFC4033], RFC 4034
|
||||
[RFC4034], and RFC 4035 [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 signature and hash algorithms
|
||||
GOST [GOST3410, GOST3411],
|
||||
and specifies how to store DNSKEY data and how to produce
|
||||
RRSIG resource records with these hash algorithms.
|
||||
|
||||
Familiarity with DNSSEC and GOST signature and hash
|
||||
algorithms is assumed in this document.
|
||||
|
||||
The term "GOST" is not officially defined, but is usually used to
|
||||
refer to the collection of the Russian cryptographic algorithms
|
||||
GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. Since GOST 28147-89
|
||||
is not used in DNSSEC, GOST will only refer to GOST R 34.10-2001
|
||||
(signatire algorithm) and GOST R 34.11-94 (hash algorithm) 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 RFC 4034 [RFC4034].
|
||||
|
||||
GOST R 34.10-2001 public keys are stored with the algorithm number {TBA1}.
|
||||
|
||||
The public key parameters are those identified by
|
||||
id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357].
|
||||
The digest parameters for signature are those identified by
|
||||
id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
|
||||
|
||||
The wire format of the public key is compatible with RFC 4491 [RFC4491]:
|
||||
|
||||
According to [GOSTR341001], a public key is a point on the elliptic
|
||||
curve Q = (x,y).
|
||||
|
||||
The wire representation of a public key MUST contain 64 octets, where the
|
||||
first 32 octets contain the little-endian representation of x and the
|
||||
second 32 octets contain the little-endian representation of y. This
|
||||
corresponds to the binary representation of (<y>256||<x>256) from
|
||||
[GOSTR341001], ch. 5.3.
|
||||
|
||||
2.1. Using a public key with existing cryptographic libraries
|
||||
|
||||
Existing GOST-aware cryptographic libraries at time of this document
|
||||
writing are capable to read GOST public keys via generic X509 API if the
|
||||
key is encoded according to RFC 4491 [RFC4491], section 2.3.2.
|
||||
|
||||
To make this encoding from the wire format of a GOST public key, prepend
|
||||
a key data with the following 37-byte sequence:
|
||||
|
||||
0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 0x12
|
||||
0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a 0x85 0x03
|
||||
0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
|
||||
|
||||
2.2. GOST DNSKEY RR Example
|
||||
|
||||
The following DNSKEY RR stores a DNS zone key for example.com
|
||||
|
||||
example.com. 86400 IN DNSKEY 256 3 {TBA1} ( RamuUwTG1r4RUqsgXu/xF6B+Y
|
||||
tJLzZEykiZ4C2Fa1gV1pI/8GA
|
||||
el2Wm69Cz5h1T9eYAQKFAGwzW
|
||||
m4Lke0E26aw== )
|
||||
|
||||
3. RRSIG Resource Records
|
||||
|
||||
The value of the signature field in the RRSIG RR follows the RFC 4490
|
||||
[RFC4490] and is calculated as follows. The values for the RDATA fields
|
||||
that precede the signature data are specified in RFC 4034 [RFC4034].
|
||||
|
||||
hash = GOSTR3411(data)
|
||||
|
||||
where "data" is the wire format data of the resource record set that is
|
||||
signed, as specified in RFC 4034 [RFC4034]. Hash MUST be calculated with
|
||||
GOST R 34.11-94 parameters identified by
|
||||
id-GostR3411-94-CryptoProParamSet [RFC4357].
|
||||
|
||||
Signature is calculated from the hash according to the GOST R 34.10-2001
|
||||
standard and its wire format is compatible with RFC 4490 [RFC4490].
|
||||
Quoting RFC 4490:
|
||||
|
||||
"The signature algorithm GOST R 34.10-2001 generates a digital
|
||||
signature in the form of two 256-bit numbers, r and s. Its octet
|
||||
string representation consists of 64 octets, where the first 32
|
||||
octets contain the big-endian representation of s and the second 32
|
||||
octets contain the big-endian representation of r."
|
||||
|
||||
4. DS Resource Records
|
||||
|
||||
GOST R 34.11-94 digest algorithm is denoted in DS RR by the digest type
|
||||
{TBA2}. The wire format of a digest value is compatible with RFC 4490
|
||||
[RFC4490]. Quoting RFC 4490:
|
||||
|
||||
"A 32-byte digest in little-endian representation."
|
||||
|
||||
The digest MUST always be calculated with GOST R 34.11-94 parameters
|
||||
identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
|
||||
|
||||
5. NSEC3 Resource Records
|
||||
|
||||
GOST R 34.11-94 digest algorithm is denoted in NSEC3 RR by the digest type
|
||||
{TBA2}. The wire format of a digest value is compatible with RFC 4490
|
||||
[RFC4490]. Quoting RFC 4490:
|
||||
|
||||
"A 32-byte digest in little-endian representation."
|
||||
|
||||
The digest MUST always be calculated with GOST R 34.11-94 parameters
|
||||
identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
|
||||
|
||||
6. Deployment Considerations
|
||||
|
||||
6.1. Key Sizes
|
||||
|
||||
According to RFC4357 [RFC4357] key size of GOST public keys MUST
|
||||
be 512 bits.
|
||||
|
||||
6.2. Signature Sizes
|
||||
|
||||
According to GOST signature algorithm [GOST3410] size of GOST signature
|
||||
is 512 bit.
|
||||
|
||||
6.3. Digest Sizes
|
||||
|
||||
According to GOST R 34.11-94 [GOST3411] size of GOST digest is 256 bit.
|
||||
|
||||
7. Implementation Considerations
|
||||
|
||||
7.1. Support for GOST signatures
|
||||
|
||||
DNSSEC aware implementations SHOULD be able to support RRSIG and
|
||||
DNSKEY resource records created with the GOST algorithms as
|
||||
defined in this document.
|
||||
|
||||
7.2. Support for NSEC3 Denial of Existence
|
||||
|
||||
RFC5155 [RFC5155] defines new algorithm identifiers for existing
|
||||
signing algorithms, to indicate that zones signed with these
|
||||
algorithm identifiers use NSEC3 instead of NSEC records to provide
|
||||
denial of existence. That mechanism was chosen to protect
|
||||
implementations predating RFC5155 from encountering resource records
|
||||
they could not know about. This document does not define such
|
||||
algorithm aliases, and support for NSEC3 denial of existence is
|
||||
implicitly signaled with support for one of the algorithms defined in
|
||||
this document.
|
||||
|
||||
7.2.1. NSEC3 in Authoritative servers
|
||||
|
||||
An authoritative server that does not implement NSEC3 MAY still serve
|
||||
zones that use GOST with NSEC denial of existence.
|
||||
|
||||
7.2.2. NSEC3 in Validators
|
||||
|
||||
A DNSSEC validator that implements GOST MUST be able to handle
|
||||
both NSEC and NSEC3 [RFC5155] negative answers. If this is not the
|
||||
case, the validator MUST treat a zone signed with GOST
|
||||
as signed with an unknown algorithm, and thus as insecure.
|
||||
|
||||
|
||||
8. IANA Considerations
|
||||
|
||||
This document updates the IANA registry "DNS SECURITY ALGORITHM
|
||||
NUMBERS -- per [RFC4035] "
|
||||
(http://www.iana.org/assignments/dns-sec-alg-numbers). The following
|
||||
entries are added to the registry:
|
||||
Zone Trans.
|
||||
Value Algorithm Mnemonic Signing Sec. References Status
|
||||
{TBA1} GOST R 34.10-2001 GOST Y * (this memo) OPTIONAL
|
||||
|
||||
This document updates the RFC 4034 [RFC4034] Digest Types assignment
|
||||
(RFC 4034, section A.2):
|
||||
|
||||
Value Algorithm Status
|
||||
{TBA2} GOST R 34.11-94 OPTIONAL
|
||||
|
||||
9. Acknowledgments
|
||||
|
||||
This document is a minor extension to RFC 4034 [RFC4034]. Also, we
|
||||
try to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509]
|
||||
and RFC 4357 [RFC4357] 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: Dmitry
|
||||
Burkov, Jaap Akkerhuis, Jelte Jansen and Wouter Wijngaards.
|
||||
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", 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.
|
||||
|
||||
[GOST3410] "Information technology. Cryptographic data security.
|
||||
Signature and verification processes of [electronic]
|
||||
digital signature.", GOST R 34.10-2001, Gosudarstvennyi
|
||||
Standard of Russian Federation, Government Committee of
|
||||
the Russia for Standards, 2001. (In Russian)
|
||||
|
||||
[GOST3411] "Information technology. Cryptographic Data Security.
|
||||
Hashing function.", GOST R 34.11-94, Gosudarstvennyi
|
||||
Standard of Russian Federation, Government Committee of
|
||||
the Russia for Standards, 1994. (In Russian)
|
||||
|
||||
[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional
|
||||
Cryptographic Algorithms for Use with GOST 28147-89,
|
||||
GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
|
||||
Algorithms", RFC 4357, January 2006.
|
||||
|
||||
[RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89,
|
||||
GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001
|
||||
Algorithms with Cryptographic Message Syntax (CMS)",
|
||||
RFC 4490, May 2006.
|
||||
|
||||
[RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST
|
||||
R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
|
||||
Algorithms with the Internet X.509 Public Key
|
||||
Infrastructure Certificate and CRL Profile", RFC 4491,
|
||||
May 2006.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
[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.
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
|
||||
Vasily Dolmatov, Ed.
|
||||
Cryptocom Ltd.
|
||||
Bolotnikovskaya, 23
|
||||
Moscow, 117303, Russian Federation
|
||||
|
||||
EMail: dol@cryptocom.ru
|
||||
|
||||
Artem Chuprina
|
||||
Cryptocom Ltd.
|
||||
Bolotnikovskaya, 23
|
||||
Moscow, 117303, Russian Federation
|
||||
|
||||
EMail: ran@cryptocom.ru
|
||||
|
||||
Igor Ustinov
|
||||
Cryptocom Ltd.
|
||||
Bolotnikovskaya, 23
|
||||
Moscow, 117303, Russian Federation
|
||||
|
||||
EMail: igus@cryptocom.ru
|
||||
|
||||
Expires December 31, 2009 [Page ]
|
||||
|
||||
|
||||
@@ -1,785 +0,0 @@
|
||||
|
||||
|
||||
|
||||
IPv6 Maintenance Working Group S. Kawamura
|
||||
Internet-Draft NEC BIGLOBE, Ltd.
|
||||
Intended status: Informational M. Kawashima
|
||||
Expires: April 21, 2010 NEC AccessTechnica, Ltd.
|
||||
October 18, 2009
|
||||
|
||||
|
||||
A Recommendation for IPv6 Address Text Representation
|
||||
draft-ietf-6man-text-addr-representation-01
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This Internet-Draft is submitted to IETF in full conformance with the
|
||||
provisions of BCP 78 and BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on April 21, 2010.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2009 IETF Trust and the persons identified as the
|
||||
document authors. All rights reserved.
|
||||
|
||||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||||
Provisions Relating to IETF Documents in effect on the date of
|
||||
publication of this document (http://trustee.ietf.org/license-info).
|
||||
Please review these documents carefully, as they describe your rights
|
||||
and restrictions with respect to this document.
|
||||
|
||||
Abstract
|
||||
|
||||
As IPv6 network grows, there will be more engineers and also non-
|
||||
engineers who will have the need to use an IPv6 address in text.
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 1]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
While the IPv6 address architecture RFC 4291 section 2.2 depicts a
|
||||
flexible model for text representation of an IPv6 address, this
|
||||
flexibility has been causing problems for operators, system
|
||||
engineers, and users. This document will describe the problems that
|
||||
a flexible text representation has been causing. This document also
|
||||
recommends a canonical representation format that best avoids
|
||||
confusion. It is expected that the canonical format is followed by
|
||||
humans and systems when representing IPv6 addresses as text, but all
|
||||
implementations must accept and be able to handle any legitimate
|
||||
RFC4291 format.
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
|
||||
2. Text Representation Flexibility of RFC4291 . . . . . . . . . . 4
|
||||
2.1. Leading Zeros in a 16 Bit Field . . . . . . . . . . . . . 4
|
||||
2.2. Zero Compression . . . . . . . . . . . . . . . . . . . . . 5
|
||||
2.3. Uppercase or Lowercase . . . . . . . . . . . . . . . . . . 5
|
||||
3. Problems Encountered with the Flexible Model . . . . . . . . . 6
|
||||
3.1. Searching . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
3.1.1. General Summary . . . . . . . . . . . . . . . . . . . 6
|
||||
3.1.2. Searching Spreadsheets and Text Files . . . . . . . . 6
|
||||
3.1.3. Searching with Whois . . . . . . . . . . . . . . . . . 6
|
||||
3.1.4. Searching for an Address in a Network Diagram . . . . 7
|
||||
3.2. Parsing and Modifying . . . . . . . . . . . . . . . . . . 7
|
||||
3.2.1. General Summary . . . . . . . . . . . . . . . . . . . 7
|
||||
3.2.2. Logging . . . . . . . . . . . . . . . . . . . . . . . 7
|
||||
3.2.3. Auditing: Case 1 . . . . . . . . . . . . . . . . . . . 8
|
||||
3.2.4. Auditing: Case 2 . . . . . . . . . . . . . . . . . . . 8
|
||||
3.2.5. Verification . . . . . . . . . . . . . . . . . . . . . 8
|
||||
3.2.6. Unexpected Modifying . . . . . . . . . . . . . . . . . 8
|
||||
3.3. Operating . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
3.3.1. General Summary . . . . . . . . . . . . . . . . . . . 8
|
||||
3.3.2. Customer Calls . . . . . . . . . . . . . . . . . . . . 9
|
||||
3.3.3. Abuse . . . . . . . . . . . . . . . . . . . . . . . . 9
|
||||
3.4. Other Minor Problems . . . . . . . . . . . . . . . . . . . 9
|
||||
3.4.1. Changing Platforms . . . . . . . . . . . . . . . . . . 9
|
||||
3.4.2. Preference in Documentation . . . . . . . . . . . . . 9
|
||||
3.4.3. Legibility . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
4. A Recommendation for IPv6 Text Representation . . . . . . . . 10
|
||||
4.1. Handling Leading Zeros in a 16 Bit Field . . . . . . . . . 10
|
||||
4.2. "::" Usage . . . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
4.2.1. Shorten As Much As Possible . . . . . . . . . . . . . 10
|
||||
4.2.2. Handling One 16 Bit 0 Field . . . . . . . . . . . . . 10
|
||||
4.2.3. Choice in Placement of "::" . . . . . . . . . . . . . 10
|
||||
4.3. Lower Case . . . . . . . . . . . . . . . . . . . . . . . . 11
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 2]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
5. Text Representation of Special Addresses . . . . . . . . . . . 11
|
||||
6. Notes on Combining IPv6 Addresses with Port Numbers . . . . . 11
|
||||
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
|
||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
|
||||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
|
||||
11.2. Informative References . . . . . . . . . . . . . . . . . . 13
|
||||
Appendix A. For Developers . . . . . . . . . . . . . . . . . . . 13
|
||||
Appendix B. Prefix Issues . . . . . . . . . . . . . . . . . . . . 13
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 3]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
A single IPv6 address can be text represented in many ways. Examples
|
||||
are shown below.
|
||||
|
||||
2001:db8:0:0:1:0:0:1
|
||||
|
||||
2001:0db8:0:0:1:0:0:1
|
||||
|
||||
2001:db8::1:0:0:1
|
||||
|
||||
2001:db8::0:1:0:0:1
|
||||
|
||||
2001:0db8::1:0:0:1
|
||||
|
||||
2001:db8:0:0:1::1
|
||||
|
||||
2001:db8:0000:0:1::1
|
||||
|
||||
2001:DB8:0:0:1::1
|
||||
|
||||
All the above point to the same IPv6 address. This flexibility has
|
||||
caused many problems for operators, systems engineers, and customers.
|
||||
The problems will be noted in Section 3. Also, a canonical
|
||||
representation format to avoid problems will be introduced in
|
||||
Section 4.
|
||||
|
||||
1.1. Requirements Language
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
|
||||
2. Text Representation Flexibility of RFC4291
|
||||
|
||||
Examples of flexibility in Section 2.2 of [RFC4291] are described
|
||||
below.
|
||||
|
||||
2.1. Leading Zeros in a 16 Bit Field
|
||||
|
||||
'It is not necessary to write the leading zeros in an individual
|
||||
field.'
|
||||
|
||||
In other words, it is also not necessary to omit leading zeros. This
|
||||
means that, it is possible to select from such as the following
|
||||
example. The final 16 bit field is different, but all these
|
||||
addresses mean the same.
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 4]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
2001:db8:aaaa:bbbb:cccc:dddd:eeee:0001
|
||||
|
||||
2001:db8:aaaa:bbbb:cccc:dddd:eeee:001
|
||||
|
||||
2001:db8:aaaa:bbbb:cccc:dddd:eeee:01
|
||||
|
||||
2001:db8:aaaa:bbbb:cccc:dddd:eeee:1
|
||||
|
||||
2.2. Zero Compression
|
||||
|
||||
'A special syntax is available to compress the zeros. The use of
|
||||
"::" indicates one or more groups of 16 bits of zeros.'
|
||||
|
||||
It is possible to select whether or not to omit just one 16 bits of
|
||||
zeros.
|
||||
|
||||
2001:db8:aaaa:bbbb:cccc:dddd::1
|
||||
|
||||
2001:db8:aaaa:bbbb:cccc:dddd:0:1
|
||||
|
||||
In case where there are more than one zero fields, there is a choice
|
||||
of how many fields can be shortened. Examples follow.
|
||||
|
||||
2001:db8:0:0:0::1
|
||||
|
||||
2001:db8:0:0::1
|
||||
|
||||
2001:db8:0::1
|
||||
|
||||
2001:db8::1
|
||||
|
||||
In addition, [RFC4291] in section 2.2 notes,
|
||||
|
||||
'The "::" can only appear once in an address.'
|
||||
|
||||
This gives a choice on where, in a single address to compress the
|
||||
zero. Examples are shown below.
|
||||
|
||||
2001:db8::aaaa:0:0:1
|
||||
|
||||
2001:db8:0:0:aaaa::1
|
||||
|
||||
2.3. Uppercase or Lowercase
|
||||
|
||||
[RFC4291] does not mention about preference of uppercase or
|
||||
lowercase. Various flavors are shown below.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 5]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
2001:db8:aaaa:bbbb:cccc:dddd:eeee:aaaa
|
||||
|
||||
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AAAA
|
||||
|
||||
2001:db8:aaaa:bbbb:cccc:dddd:eeee:AaAa
|
||||
|
||||
|
||||
3. Problems Encountered with the Flexible Model
|
||||
|
||||
3.1. Searching
|
||||
|
||||
3.1.1. General Summary
|
||||
|
||||
A search of an IPv6 address if conducted through a UNIX system is
|
||||
usually case sensitive and extended options to allow for regular
|
||||
expression use will come in handy. However, there are many
|
||||
applications in the Internet today that do not provide this
|
||||
capability. When searching for an IPv6 address in such systems, the
|
||||
system engineer will have to try each and every possibility to search
|
||||
for an address. This has critical impacts especially when trying to
|
||||
deploy IPv6 over an enterprise network.
|
||||
|
||||
3.1.2. Searching Spreadsheets and Text Files
|
||||
|
||||
Spreadsheet applications and text editors on GUI systems, rarely have
|
||||
the ability to search for a text using regular expression. Moreover,
|
||||
there are many non-engineers (who are not aware of case sensitivity
|
||||
and regular expression use) that use these application to manage IP
|
||||
addresses. This has worked quite well with IPv4 since text
|
||||
representation in IPv4 has very little flexibility. There is no
|
||||
incentive to encourage these non-engineers to change their tool or
|
||||
learn regular expression when they decide to go dual-stack. If the
|
||||
entry in the spreadsheet reads, 2001:db8::1:0:0:1, but the search was
|
||||
conducted as 2001:db8:0:0:1::1, this will show a result of no match.
|
||||
One example where this will cause problem is, when the search is
|
||||
being conducted to assign a new address from a pool, and a check was
|
||||
being done to see if it was not in use. This may cause problems to
|
||||
the end-hosts or end-users. This type of address management is very
|
||||
often seen in enterprise networks and also in ISPs.
|
||||
|
||||
3.1.3. Searching with Whois
|
||||
|
||||
The "whois" utility is used by a wide range of people today. When a
|
||||
record is set to a database, one will likely check the output to see
|
||||
if the entry is correct. If an entity was recorded as 2001:db8::/48,
|
||||
but the whois output showed 2001:0db8:0000::/48, most non-engineers
|
||||
would think that their input was wrong, and will likely retry several
|
||||
times or make a frustrated call to the database hostmaster. If there
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 6]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
was a need to register the same address on different systems, and
|
||||
each system showed a different text representation, this would
|
||||
confuse people even more. Although this document focuses on
|
||||
addresses rather than prefixes, this is worth mentioning since
|
||||
problems encountered are mostly equal.
|
||||
|
||||
3.1.4. Searching for an Address in a Network Diagram
|
||||
|
||||
Network diagrams and blue-prints contain IP addresses as allocated to
|
||||
system devices. In times of trouble shooting, there may be a need to
|
||||
search through a diagram to find the point of failure (for example,
|
||||
if a traceroute stopped at 2001:db8::1, one would search the diagram
|
||||
for that address). This is a technique quite often in use in
|
||||
enterprise networks and managed services. Again, the different
|
||||
flavors of text representation will result in a time-consuming
|
||||
search, leading to longer MTTR in times of trouble.
|
||||
|
||||
3.2. Parsing and Modifying
|
||||
|
||||
3.2.1. General Summary
|
||||
|
||||
With all the possible text representation ways, each application must
|
||||
include a module, object, link, etc. to a function that will parse
|
||||
IPv6 addresses in a manner that no matter how it is represented, they
|
||||
will mean the same address. This is not too much a problem if the
|
||||
output is to be just 'read' or 'managed' by a network engineer.
|
||||
However, many system engineers who integrate complex computer systems
|
||||
to corporate customers will have difficulties finding that their
|
||||
favorite tool will not have this function, or will encounter
|
||||
difficulties such as having to rewrite their macro's or scripts for
|
||||
their customers. It must be noted that each additional line of a
|
||||
program will result in increased development fees that will be
|
||||
charged to the customers.
|
||||
|
||||
3.2.2. Logging
|
||||
|
||||
If an application were to output a log summary that represented the
|
||||
address in full (such as 2001:0db8:0000:0000:1111:2222:3333:4444),
|
||||
the output would be highly unreadable compared to the IPv4 output.
|
||||
The address would have to be parsed and reformed to make it useful
|
||||
for human reading. This will result in additional code on the
|
||||
applications which will result in extra fees charged to the
|
||||
customers. Sometimes, logging for critical systems is done by
|
||||
mirroring the same traffic to two different systems. Care must be
|
||||
taken that no matter what the log output is, the logs should be
|
||||
parsed so they will mean the same.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 7]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
3.2.3. Auditing: Case 1
|
||||
|
||||
When a router or any other network appliance machine configuration is
|
||||
audited, there are many methods to compare the configuration
|
||||
information of a node. Sometimes, auditing will be done by just
|
||||
comparing the changes made each day. In this case, if configuration
|
||||
was done such that 2001:db8::1 was changed to 2001:0db8:0000:0000:
|
||||
0000:0000:0000:0001 just because the new engineer on the block felt
|
||||
it was better, a simple diff will tell you that a different address
|
||||
was configured. If this was done on a wide scale network, people
|
||||
will be focusing on 'why the extra zeros were put in' instead of
|
||||
doing any real auditing. Lots of tools are just plain 'diff's that
|
||||
do not take into account address representation rules.
|
||||
|
||||
3.2.4. Auditing: Case 2
|
||||
|
||||
Node configurations will be matched against an information system
|
||||
that manages IP addresses. If output notation is different, there
|
||||
will need to be a script that is implemented to cover for this. An
|
||||
SNMP GET of an interface address and text representation in a humanly
|
||||
written text file is highly unlikely to match on first try.
|
||||
|
||||
3.2.5. Verification
|
||||
|
||||
Some protocols require certain data fields to be verified. One
|
||||
example of this is X.509 certificates. If an IPv6 address was
|
||||
embedded in one of the fields in a certificate, and the verification
|
||||
was done by just a simple textual comparison, the certificate may be
|
||||
maistakenly shown as being invalid due to a difference in text
|
||||
representation methods.
|
||||
|
||||
3.2.6. Unexpected Modifying
|
||||
|
||||
Sometimes, a system will take an address and modify it as a
|
||||
convenience. For example, a system may take an input of
|
||||
2001:0db8:0::1 and make the output 2001:db8::1 (which is seen in some
|
||||
RIR databases). If the zeros were input for a reason, the outcome
|
||||
may be somewhat unexpected.
|
||||
|
||||
3.3. Operating
|
||||
|
||||
3.3.1. General Summary
|
||||
|
||||
When an operator sets an IPv6 address of a system as 2001:db8:0:0:1:
|
||||
0:0:1, the system may take the address and show the configuration
|
||||
result as 2001:DB8::1:0:0:1. A distinguished engineer will know that
|
||||
the right address is set, but an operator, or a customer that is
|
||||
communicating with the operator to solve a problem, is usually not as
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 8]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
distinguished as we would like. Again, the extra load in checking
|
||||
that the IP address is the same as was intended, will result in fees
|
||||
that will be charged to the customers.
|
||||
|
||||
3.3.2. Customer Calls
|
||||
|
||||
When a customer calls to inquire about a suspected outage, IPv6
|
||||
address representation should be handled with care. Not all
|
||||
customers are engineers nor have the same skill in IPv6 technology.
|
||||
The NOC will have to take extra steps to humanly parse the address to
|
||||
avoid having to explain to the customers that 2001:db8:0:1::1 is the
|
||||
same as 2001:db8::1:0:0:0:1. This is one thing that will never
|
||||
happen in IPv4 because IPv4 address cannot be abbreviated.
|
||||
|
||||
3.3.3. Abuse
|
||||
|
||||
Network abuse is reported along with the abusing IP address. This
|
||||
'reporting' could take any shape or form of the flexible model. A
|
||||
team that handles network abuse must be able to tell the difference
|
||||
between a 2001:db8::1:0:1 and 2001:db8:1::0:1. Mistakes in the
|
||||
placement of the "::" will result in a critical situation. A system
|
||||
that handles these incidents should be able to handle any type of
|
||||
input and parse it in a correct manner. Also, incidents are reported
|
||||
over the phone. It is unnecessary to report if the letter is an
|
||||
uppercase or lowercase. However, when a letter is spelled uppercase,
|
||||
people tend to clarify that it is uppercase, which is unnecessary
|
||||
information.
|
||||
|
||||
3.4. Other Minor Problems
|
||||
|
||||
3.4.1. Changing Platforms
|
||||
|
||||
When an engineer decides to change the platform of a running service,
|
||||
the same code may not work as expected due to the difference in IPv6
|
||||
address text representation. Usually, a change in a platform (e.g.
|
||||
Unix to Windows, Cisco to Juniper) will result in a major change of
|
||||
code, but flexibility in address representation will increase the
|
||||
work load which will again, result in fees that will be charged to
|
||||
the customers, and also longer down time of systems.
|
||||
|
||||
3.4.2. Preference in Documentation
|
||||
|
||||
A document that is edited by more than one author, may become harder
|
||||
to read.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 9]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
3.4.3. Legibility
|
||||
|
||||
Capital case D and 0 can be quite often misread. Capital B and 8 can
|
||||
also be misread.
|
||||
|
||||
|
||||
4. A Recommendation for IPv6 Text Representation
|
||||
|
||||
A recommendation for a canonical text representation format of IPv6
|
||||
addresses is presented in this section. The recommendation in this
|
||||
document is one that, complies fully with [RFC4291], is implemented
|
||||
by various operating systems, and is human friendly. The
|
||||
recommendation in this document SHOULD be followed by humans and
|
||||
systems when generating an address to represent as text, but all
|
||||
implementations MUST accept any legitimate [RFC4291] format.
|
||||
|
||||
4.1. Handling Leading Zeros in a 16 Bit Field
|
||||
|
||||
Leading zeros should be chopped for human legibility and easier
|
||||
searching. Also, a single 16 bit 0000 field should be represented as
|
||||
just 0. Place holder zeros are often cause of misreading.
|
||||
|
||||
4.2. "::" Usage
|
||||
|
||||
4.2.1. Shorten As Much As Possible
|
||||
|
||||
The use of "::" should be used to its maximum capability (i.e. 2001:
|
||||
db8::0:1 is not considered as clean representation).
|
||||
|
||||
4.2.2. Handling One 16 Bit 0 Field
|
||||
|
||||
"::" should not be used to shorten just one 16 bit 0 field for it
|
||||
would tend to mislead that there are more than one 16 bit field that
|
||||
is shortened.
|
||||
|
||||
4.2.3. Choice in Placement of "::"
|
||||
|
||||
When there is an alternative choice in the placement of a "::", the
|
||||
longest run of consecutive 16 bit 0 fields should be shortened (i.e.
|
||||
latter is shortened in 2001:0:0:1:0:0:0:1). When the length of the
|
||||
consecutive 16 bit 0 fields are equal (i.e. 2001:db8:0:0:1:0:0:1),
|
||||
the former is shortened. This is consistent with many current
|
||||
implementations. One idea to avoid any confusion, is for the
|
||||
operator to not use 16 bit field 0 in the first 64 bits. By nature
|
||||
IPv6 addresses are usually assigned or allocated to end-users as
|
||||
longer than 32 bits (typically 48 bits or longer).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 10]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
4.3. Lower Case
|
||||
|
||||
Recent implementations tend to represent IPv6 address as lower case.
|
||||
It is better to use lower case to avoid problems such as described in
|
||||
section 3.3.3 and 3.4.3.
|
||||
|
||||
|
||||
5. Text Representation of Special Addresses
|
||||
|
||||
Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and
|
||||
IPv4-translated addresses [RFC2765] have IPv4 addresses embedded in
|
||||
the low-order 32 bits of the address. These addresses have special
|
||||
representation that may mix hexadecimal and decimal notations. In
|
||||
cases where there is a choice of whether to express the address as
|
||||
fully hexadecimal or hexadecimal and decimal mixed, and if the
|
||||
address type can be distinguished as having IPv4 addresses embedded
|
||||
in the lower 32 bits solely from the 128bits of the address field
|
||||
itself, mixed notation is the better choice. However, there may be
|
||||
situations where hexadecimal representation is chosen to meet certain
|
||||
needs. Addressing those needs is out of the scope of this document.
|
||||
The text representation method noted in Section 4 should be applied
|
||||
for the leading hexadecimal part (i.e. ::ffff:192.0.2.1 instead of
|
||||
0:0:0:0:0:ffff:192.0.2.1).
|
||||
|
||||
|
||||
6. Notes on Combining IPv6 Addresses with Port Numbers
|
||||
|
||||
When IPv6 addresses and port numbers are represented in text combined
|
||||
together, there seems to be many different ways to do so. Examples
|
||||
are shown below.
|
||||
|
||||
o [2001:db8::1]:80
|
||||
|
||||
o 2001:db8::1:80
|
||||
|
||||
o 2001:db8::1.80
|
||||
|
||||
o 2001:db8::1 port 80
|
||||
|
||||
o 2001:db8::1p80
|
||||
|
||||
o 2001:db8::1#80
|
||||
|
||||
The situation is not much different in IPv4, but the most ambiguous
|
||||
case with IPv6 is the second bullet. This is due to the "::"usage in
|
||||
IPv6 addresses. This style is not recommended for its ambiguity.
|
||||
The [] style as expressed in [RFC3986] is recommended. Other styles
|
||||
are acceptable when cross-platform portability does not become an
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 11]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
issue.
|
||||
|
||||
|
||||
7. Conclusion
|
||||
|
||||
The recommended format of text representing an IPv6 address is
|
||||
summarized as follows.
|
||||
|
||||
(1) omit leading zeros in a 16 bit field
|
||||
|
||||
(2) when using "::", shorten consecutive zero fields to their
|
||||
maximum extent (leave no zero fields behind).
|
||||
|
||||
(3) "::" used where shortens address the most
|
||||
|
||||
(4) "::" used in the former part in case of a tie breaker
|
||||
|
||||
(5) do not shorten one 16 bit 0 field, but always shorten when
|
||||
there are two or more consecutive 16 bit 0 fields
|
||||
|
||||
(6) use lower case
|
||||
|
||||
Hints for developers are written in the Appendix section.
|
||||
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
None.
|
||||
|
||||
|
||||
9. IANA Considerations
|
||||
|
||||
None.
|
||||
|
||||
|
||||
10. Acknowledgements
|
||||
|
||||
The authors would like to thank Jan Zorz, Randy Bush, Yuichi Minami,
|
||||
Toshimitsu Matsuura for their generous and helpful comments in kick
|
||||
starting this document. We also would like to thank Brian Carpenter,
|
||||
Akira Kato, Juergen Schoenwaelder, Antonio Querubin, Dave Thaler,
|
||||
Brian Haley, Suresh Krishnan, Jerry Huang, Roman Donchenko, Heikki
|
||||
Vatiainen for their input. Also a very special thanks to Ron Bonica,
|
||||
Fred Baker, Brian Haberman, Robert Hinden, Jari Arkko, and Kurt
|
||||
Lindqvist for their support in bringing this document to the light of
|
||||
IETF working groups.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 12]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
11. References
|
||||
|
||||
11.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||||
Architecture", RFC 4291, February 2006.
|
||||
|
||||
11.2. Informative References
|
||||
|
||||
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
|
||||
(SIIT)", RFC 2765, February 2000.
|
||||
|
||||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
|
||||
Resource Identifier (URI): Generic Syntax", STD 66,
|
||||
RFC 3986, January 2005.
|
||||
|
||||
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
|
||||
Castro, "Application Aspects of IPv6 Transition",
|
||||
RFC 4038, March 2005.
|
||||
|
||||
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
|
||||
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
|
||||
March 2008.
|
||||
|
||||
|
||||
Appendix A. For Developers
|
||||
|
||||
We recommend that developers use display routines that conform to
|
||||
these rules. For example, the usage of getnameinfo() with flags
|
||||
argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output,
|
||||
except for the special addresses notes in Section 5. The function
|
||||
inet_ntop() of FreeBSD7.0 is a good C code reference, but should not
|
||||
be called directly. See [RFC4038] for details.
|
||||
|
||||
|
||||
Appendix B. Prefix Issues
|
||||
|
||||
Problems with prefixes are just the same as problems encountered with
|
||||
addresses. Text representation method of IPv6 prefixes should be no
|
||||
different from that of IPv6 addresses.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 13]
|
||||
|
||||
Internet-Draft IPv6 Text Representation October 2009
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Seiichi Kawamura
|
||||
NEC BIGLOBE, Ltd.
|
||||
14-22, Shibaura 4-chome
|
||||
Minatoku, Tokyo 108-8558
|
||||
JAPAN
|
||||
|
||||
Phone: +81 3 3798 6085
|
||||
Email: kawamucho@mesh.ad.jp
|
||||
|
||||
|
||||
Masanobu Kawashima
|
||||
NEC AccessTechnica, Ltd.
|
||||
800, Shimomata
|
||||
Kakegawa-shi, Shizuoka 436-8501
|
||||
JAPAN
|
||||
|
||||
Phone: +81 537 23 9655
|
||||
Email: kawashimam@necat.nec.co.jp
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Kawamura & Kawashima Expires April 21, 2010 [Page 14]
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -1,448 +0,0 @@
|
||||
|
||||
|
||||
|
||||
DNSEXT R. Bellis
|
||||
Internet-Draft Nominet UK
|
||||
Updates: 1035, 1123 October 26, 2009
|
||||
(if approved)
|
||||
Intended status: Standards Track
|
||||
Expires: April 29, 2010
|
||||
|
||||
|
||||
DNS Transport over TCP
|
||||
draft-ietf-dnsext-dns-tcp-requirements-01
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This Internet-Draft is submitted to IETF in full conformance with the
|
||||
provisions of BCP 78 and BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on April 29, 2010.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2009 IETF Trust and the persons identified as the
|
||||
document authors. All rights reserved.
|
||||
|
||||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||||
Provisions Relating to IETF Documents in effect on the date of
|
||||
publication of this document (http://trustee.ietf.org/license-info).
|
||||
Please review these documents carefully, as they describe your rights
|
||||
and restrictions with respect to this document.
|
||||
|
||||
Abstract
|
||||
|
||||
This document updates the requirements for the support of the TCP
|
||||
|
||||
|
||||
|
||||
Bellis Expires April 29, 2010 [Page 1]
|
||||
|
||||
Internet-Draft DNS Transport over TCP October 2009
|
||||
|
||||
|
||||
protocol for the transport of DNS traffic.
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
|
||||
2. Terminology used in this document . . . . . . . . . . . . . . . 3
|
||||
|
||||
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
|
||||
4. Transport Protocol Selection . . . . . . . . . . . . . . . . . 4
|
||||
|
||||
5. Dormant Connection Handling . . . . . . . . . . . . . . . . . . 5
|
||||
|
||||
6. Response re-ordering . . . . . . . . . . . . . . . . . . . . . 6
|
||||
|
||||
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
|
||||
|
||||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
|
||||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
|
||||
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
|
||||
|
||||
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 7
|
||||
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires April 29, 2010 [Page 2]
|
||||
|
||||
Internet-Draft DNS Transport over TCP October 2009
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Most DNS [RFC1035] transactions take place over the UDP [RFC0792]
|
||||
protocol. The TCP [RFC0793] protocol is used for zone transfers and
|
||||
is supported by many implementations for the transfer of other
|
||||
packets which exceed the protocol's original 512 byte packet-size
|
||||
limit.
|
||||
|
||||
Section 6.1.3.2 of [RFC1123] states:
|
||||
|
||||
DNS resolvers and recursive servers MUST support UDP, and SHOULD
|
||||
support TCP, for sending (non-zone-transfer) queries.
|
||||
|
||||
However, some implementors have taken the text quoted above to mean
|
||||
that TCP support is truly optional for typical DNS operation.
|
||||
|
||||
This document normatively updates the core DNS protocol
|
||||
specifications such that (except in very limited circumstances)
|
||||
support for the TCP protocol is henceforth REQUIRED.
|
||||
|
||||
|
||||
2. Terminology used in this document
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
|
||||
3. Discussion
|
||||
|
||||
In the absence of EDNS0 (see below) the normal behaviour of any DNS
|
||||
server needing to send a UDP response that exceeds that 512 byte
|
||||
limit is for the server to truncate the response at the 512 byte
|
||||
limit and set the TC flag in the response header. When the client
|
||||
receives such a response it takes the TC flag as notice that it
|
||||
should retry over TCP instead.
|
||||
|
||||
RFC 1123 also says:
|
||||
|
||||
... it is also clear that some new DNS record types defined in the
|
||||
future will contain information exceeding the 512 byte limit that
|
||||
applies to UDP, and hence will require TCP. Thus, resolvers and
|
||||
name servers should implement TCP services as a backup to UDP
|
||||
today, with the knowledge that they will require the TCP service
|
||||
in the future.
|
||||
|
||||
Existing deployments of DNSSEC [RFC4033] have shown that truncation
|
||||
at the 512 byte boundary is now commonplace. For example an NXDOMAIN
|
||||
|
||||
|
||||
|
||||
Bellis Expires April 29, 2010 [Page 3]
|
||||
|
||||
Internet-Draft DNS Transport over TCP October 2009
|
||||
|
||||
|
||||
(RCODE == 3) response from a DNSSEC signed zone using NSEC3 [RFC5155]
|
||||
is almost invariably longer than 512 bytes.
|
||||
|
||||
Since the original core specifications for DNS were written, the
|
||||
Extension Mechanisms for DNS (EDNS0 [RFC2671]) have been introduced.
|
||||
These extensions can be used to indicate that the client is prepared
|
||||
to receive UDP responses longer than 512 bytes. An EDNS0 compatible
|
||||
server receiving a request from an EDNS0 compatible client may send
|
||||
UDP packets up to that client's announced buffer size without
|
||||
truncation.
|
||||
|
||||
However, transport of UDP packets which exceed the size of the path
|
||||
MTU has been found to be unreliable in some circumstances because of
|
||||
IP packet fragmentation. Many firewalls routinely block fragmented
|
||||
IP packets, and some implementations lack the software logic
|
||||
necessary to reassemble a fragmented datagram. Worse still, some
|
||||
devices deliberately refuse to handle DNS packets containing EDNS0
|
||||
options. Other issues relating to UDP transport and packet size are
|
||||
discussed in [RFC5625].
|
||||
|
||||
The MTU most commonly found in the core of the Internet is around
|
||||
1500 bytes, and even that limit is routinely exceeded by DNSSEC
|
||||
signed responses.
|
||||
|
||||
The future that was anticipated in RFC 1123 has arrived, and the only
|
||||
standardised mechanism which may have resolved the packet size issue
|
||||
has been found inadequate.
|
||||
|
||||
|
||||
4. Transport Protocol Selection
|
||||
|
||||
All DNS implementations MUST support both UDP and TCP transport
|
||||
protocols, except as set out below.
|
||||
|
||||
On a case by case basis, authoritative DNS server operators MAY elect
|
||||
to disable DNS transport over TCP if all of the following conditions
|
||||
are satisfied:
|
||||
|
||||
o the server is authoritative only
|
||||
o the server does not support AXFR
|
||||
o all requests and responses are guaranteed to be <= 512 bytes
|
||||
|
||||
A general purpose stub resolver implementation (e.g. an operating
|
||||
system's DNS resolution library) MUST support TCP since to do
|
||||
otherwise would limit its interoperability with its own clients and
|
||||
with upstream servers.
|
||||
|
||||
A proprietary stub resolver implementation MAY omit support for TCP
|
||||
|
||||
|
||||
|
||||
Bellis Expires April 29, 2010 [Page 4]
|
||||
|
||||
Internet-Draft DNS Transport over TCP October 2009
|
||||
|
||||
|
||||
if it is operating in an environment where truncation can never
|
||||
occur, or if it is prepared to accept a DNS lookup failure should
|
||||
truncation occur.
|
||||
|
||||
A recursive resolver or forwarder MUST support TCP so that it does
|
||||
not prevent long responses from a TCP-capable server from reaching
|
||||
its TCP-capable clients.
|
||||
|
||||
Regarding the choice of when to use UDP or TCP, RFC 1123 says:
|
||||
|
||||
... a DNS resolver or server that is sending a non-zone-transfer
|
||||
query MUST send a UDP query first.
|
||||
|
||||
That requirement is hereby relaxed. A resolver SHOULD send a UDP
|
||||
query first, but MAY elect to send a TCP query instead if it has good
|
||||
reason to expect the response would be truncated if it were sent over
|
||||
UDP (with or without EDNS0) or for other operational reasons.
|
||||
|
||||
|
||||
5. Dormant Connection Handling
|
||||
|
||||
Section 4.2.2 of [RFC1035] says:
|
||||
|
||||
If the server needs to close a dormant connection to reclaim
|
||||
resources, it should wait until the connection has been idle for a
|
||||
period on the order of two minutes.
|
||||
|
||||
Other more modern protocols (e.g. HTTP [RFC2616]) have support for
|
||||
persistent TCP connections and operational experience has shown that
|
||||
long timeouts can easily cause resource exhaustion and poor response
|
||||
under heavy load. Intentionally opening many connections and leaving
|
||||
them dormant can trivially create a "denial of service" attack.
|
||||
|
||||
This document therefore RECOMMENDS that the idle period should be of
|
||||
the order of TBD seconds.
|
||||
|
||||
Servers MAY allow dormant connections to remain open for longer
|
||||
periods, but for the avoidance of doubt persistent DNS connections
|
||||
should generally be considered to be as much for the server's benefit
|
||||
as for the client's. Therefore if the server needs to unilaterally
|
||||
close a dormant TCP connection it MUST be free to do so whenever
|
||||
required.
|
||||
|
||||
Further recommendations for the tuning of TCP parameters to allow
|
||||
higher throughput or improved resiliency against denial of service
|
||||
attacks are (currently) outside the scope of this document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires April 29, 2010 [Page 5]
|
||||
|
||||
Internet-Draft DNS Transport over TCP October 2009
|
||||
|
||||
|
||||
6. Response re-ordering
|
||||
|
||||
RFC 1035 is ambiguous on the question of whether TCP queries may be
|
||||
re-ordered - the only relevant text is in Section 4.2.1 which relates
|
||||
to UDP:
|
||||
|
||||
Queries or their responses may be reordered by the network, or by
|
||||
processing in name servers, so resolvers should not depend on them
|
||||
being returned in order.
|
||||
|
||||
For the avoidance of future doubt, this requirement is clarified.
|
||||
Client resolvers MUST be able to process responses which arrive in a
|
||||
different order to that in which the requests were sent, regardless
|
||||
of the transport protocol in use.
|
||||
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
Some DNS server operators have expressed concern that wider use of
|
||||
DNS over TCP will expose them to a higher risk of "denial of service"
|
||||
attacks.
|
||||
|
||||
Many large authoritative DNS operators including all but one of the
|
||||
root servers and the vast majority of TLDs already support TCP and
|
||||
attacks against them are infrequent and very rarely successful.
|
||||
|
||||
Operators of recursive servers should ensure that they only accept
|
||||
connections from expected clients, and do not accept them from
|
||||
unknown sources. In the case of UDP traffic this will protect
|
||||
against reflector attacks [RFC5358] and in the case of TCP traffic it
|
||||
will prevent an unknown client from exhausting the server's limits on
|
||||
the number of concurrent connections.
|
||||
|
||||
|
||||
8. IANA Considerations
|
||||
|
||||
This document requests no IANA actions.
|
||||
|
||||
|
||||
9. References
|
||||
|
||||
9.1. Normative References
|
||||
|
||||
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
|
||||
RFC 792, September 1981.
|
||||
|
||||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
|
||||
RFC 793, September 1981.
|
||||
|
||||
|
||||
|
||||
Bellis Expires April 29, 2010 [Page 6]
|
||||
|
||||
Internet-Draft DNS Transport over TCP October 2009
|
||||
|
||||
|
||||
[RFC1035] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
|
||||
and Support", STD 3, RFC 1123, October 1989.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
|
||||
RFC 2671, August 1999.
|
||||
|
||||
9.2. Informative References
|
||||
|
||||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
|
||||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
|
||||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
|
||||
|
||||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements",
|
||||
RFC 4033, March 2005.
|
||||
|
||||
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
|
||||
Security (DNSSEC) Hashed Authenticated Denial of
|
||||
Existence", RFC 5155, March 2008.
|
||||
|
||||
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
|
||||
Nameservers in Reflector Attacks", BCP 140, RFC 5358,
|
||||
October 2008.
|
||||
|
||||
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
|
||||
BCP 152, RFC 5625, August 2009.
|
||||
|
||||
|
||||
Appendix A. Change Log
|
||||
|
||||
NB: to be removed by the RFC Editor before publication.
|
||||
|
||||
draft-ietf-dnsext-dns-tcp-requirements-01
|
||||
Addition of response ordering section
|
||||
Various minor editorial changes from WG reviewers
|
||||
|
||||
draft-ietf-dnsext-dns-tcp-requirements-00
|
||||
Initial draft
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires April 29, 2010 [Page 7]
|
||||
|
||||
Internet-Draft DNS Transport over TCP October 2009
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Ray Bellis
|
||||
Nominet UK
|
||||
Edmund Halley Road
|
||||
Oxford OX4 4DQ
|
||||
United Kingdom
|
||||
|
||||
Phone: +44 1865 332211
|
||||
Email: ray.bellis@nominet.org.uk
|
||||
URI: http://www.nominet.org.uk/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires April 29, 2010 [Page 8]
|
||||
|
||||
@@ -1,728 +0,0 @@
|
||||
|
||||
|
||||
|
||||
DNSEXT R. Bellis
|
||||
Internet-Draft Nominet UK
|
||||
Intended status: BCP April 23, 2009
|
||||
Expires: October 25, 2009
|
||||
|
||||
|
||||
DNS Proxy Implementation Guidelines
|
||||
draft-ietf-dnsext-dnsproxy-05
|
||||
|
||||
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 October 25, 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 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 provides guidelines for the implementation of DNS
|
||||
proxies, as found in broadband gateways and other similar network
|
||||
devices.
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 1]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
|
||||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
|
||||
3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3
|
||||
|
||||
4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4
|
||||
4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4
|
||||
4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4
|
||||
4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5
|
||||
4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5
|
||||
4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 6
|
||||
4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6
|
||||
4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6
|
||||
4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7
|
||||
|
||||
5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7
|
||||
5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 8
|
||||
5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8
|
||||
5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
|
||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
|
||||
6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9
|
||||
6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10
|
||||
6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10
|
||||
|
||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
|
||||
|
||||
8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
||||
|
||||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
|
||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
|
||||
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
|
||||
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 2]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Research has found ([SAC035], [DOTSE]) that many commonly-used
|
||||
broadband gateways (and similar devices) contain DNS proxies which
|
||||
are incompatible in various ways with current DNS standards.
|
||||
|
||||
These proxies are usually simple DNS forwarders, but typically do not
|
||||
have any caching capabilities. The proxy serves as a convenient
|
||||
default DNS resolver for clients on the LAN, but relies on an
|
||||
upstream resolver (e.g. at an ISP) to perform recursive DNS lookups.
|
||||
|
||||
Note that to ensure full DNS protocol interoperability it is
|
||||
preferred that client stub resolvers should communicate directly with
|
||||
full-feature upstream recursive resolvers wherever possible.
|
||||
|
||||
That notwithstanding, this document describes the incompatibilities
|
||||
that have been discovered and offers guidelines to implementors on
|
||||
how to provide better interoperability in those cases where the
|
||||
client must use the broadband gateway's DNS proxy.
|
||||
|
||||
|
||||
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].
|
||||
|
||||
|
||||
3. The Transparency Principle
|
||||
|
||||
It is not considered practical for a simple DNS proxy to implement
|
||||
all current and future DNS features.
|
||||
|
||||
There are several reasons why this is the case:
|
||||
|
||||
o broadband gateways usually have limited hardware resources
|
||||
o firmware upgrade cycles are long, and many users do not routinely
|
||||
apply upgrades when they become available
|
||||
o no-one knows what those future DNS features will be, nor how they
|
||||
might be implemented
|
||||
o it would substantially complicate the configuration UI of the
|
||||
device
|
||||
|
||||
Furthermore some modern DNS protocol extensions (see e.g. EDNS0,
|
||||
below) are intended to be used as "hop-by-hop" mechanisms. If the
|
||||
DNS proxy is considered to be such a "hop" in the resolution chain,
|
||||
then for it to function correctly, it would need to be fully
|
||||
compliant with all such mechanisms.
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 3]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
[SAC035] shows that the more actively a proxy participates in the DNS
|
||||
protocol then the more likely it is that it will somehow interfere
|
||||
with the flow of messages between the DNS client and the upstream
|
||||
recursive resolvers.
|
||||
|
||||
The role of the proxy should therefore be no more and no less than to
|
||||
receive DNS requests from clients on the LAN side, forward those
|
||||
verbatim to one of the known upstream recursive resolvers on the WAN
|
||||
side, and ensure that the whole response is returned verbatim to the
|
||||
original client.
|
||||
|
||||
It is RECOMMENDED that proxies should be as transparent as possible,
|
||||
such that any "hop-by-hop" mechanisms or newly introduced protocol
|
||||
extensions operate as if the proxy were not there.
|
||||
|
||||
Except when required to enforce an active security or network policy
|
||||
(such as maintaining a pre-authentication "walled garden"), end-users
|
||||
SHOULD be able to send their DNS queries to specified upstream
|
||||
resolvers, thereby bypassing the proxy altogether. In this case, the
|
||||
gateway SHOULD NOT modify the DNS request or response packets in any
|
||||
way.
|
||||
|
||||
|
||||
4. Protocol Conformance
|
||||
|
||||
4.1. Unexpected Flags and Data
|
||||
|
||||
The Transparency Principle above, when combined with Postel's
|
||||
Robustness Principle [RFC0793], suggests that DNS proxies should not
|
||||
arbitrarily reject or otherwise drop requests or responses based on
|
||||
perceived non-compliance with standards.
|
||||
|
||||
For example, some proxies have been observed to drop any packet
|
||||
containing either the "Authentic Data" (AD) or "Checking Disabled"
|
||||
(CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035]
|
||||
originally specified that these unused "Z" flag bits "MUST" be zero.
|
||||
However these flag bits were always intended to be reserved for
|
||||
future use, so refusing to proxy any packet containing these flags
|
||||
(now that uses for those flags have indeed been defined) is not
|
||||
appropriate.
|
||||
|
||||
Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown
|
||||
DNS flags and proxy those packets as usual.
|
||||
|
||||
4.2. Label Compression
|
||||
|
||||
Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 4]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
Proxies MUST forward packets regardless of the presence or absence of
|
||||
compressed labels therein.
|
||||
|
||||
4.3. Unknown Resource Record Types
|
||||
|
||||
[RFC3597] requires that resolvers MUST handle Resource Records (RRs)
|
||||
of unknown type transparently.
|
||||
|
||||
All requests and responses MUST be proxied regardless of the values
|
||||
of the QTYPE and QCLASS fields.
|
||||
|
||||
Similarly all responses MUST be proxied regardless of the values of
|
||||
the TYPE and CLASS fields of any Resource Record therein.
|
||||
|
||||
4.4. Packet Size Limits
|
||||
|
||||
[RFC1035] specifies that the maximum size of the DNS payload in a UDP
|
||||
packet is 512 octets. Where the required portions of a response
|
||||
would not fit inside that limit the DNS server MUST set the
|
||||
"TrunCation" (TC) bit in the DNS response header to indicate that
|
||||
truncation has occurred. There are however two standard mechanisms
|
||||
(described in Section 4.4.1 and Section 4.4.2) for transporting
|
||||
responses larger than 512 octets.
|
||||
|
||||
Many proxies have been observed to truncate all responses at 512
|
||||
octets, and others at a packet size related to the WAN MTU, in either
|
||||
case doing so without correctly setting the TC bit.
|
||||
|
||||
Other proxies have been observed to remove the TC bit in server
|
||||
responses which correctly had the TC bit set by the server.
|
||||
|
||||
If a DNS response is truncated but the TC bit is not set then client
|
||||
failures may result. In particular a naive DNS client library might
|
||||
suffer crashes due to reading beyond the end of the data actually
|
||||
received.
|
||||
|
||||
Since UDP packets larger than 512 octets are now expected in normal
|
||||
operation, proxies SHOULD NOT truncate UDP packets that exceed that
|
||||
size. See Section 4.4.3 for recommendations for packet sizes
|
||||
exceeding the WAN MTU.
|
||||
|
||||
If a proxy must unilaterally truncate a response then the proxy MUST
|
||||
set the TC bit. Similarly, proxies MUST NOT remove the TC bit from
|
||||
responses.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 5]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
4.4.1. TCP Transport
|
||||
|
||||
Should a UDP query fail because of truncation, the standard fail-over
|
||||
mechanism is to retry the query using TCP, as described in section
|
||||
6.1.3.2 of [RFC1123].
|
||||
|
||||
DNS proxies SHOULD therefore be prepared to receive and forward
|
||||
queries over TCP.
|
||||
|
||||
Note that it is unlikely that a client would send a request over TCP
|
||||
unless it had already received a truncated UDP response. Some
|
||||
"smart" proxies have been observed to first forward any request
|
||||
received over TCP to an upstream resolver over UDP, only for the
|
||||
response to be truncated, causing the proxy to retry over TCP. Such
|
||||
behaviour increases network traffic and causes delay in DNS
|
||||
resolution since the initial UDP request is doomed to fail.
|
||||
|
||||
Therefore whenever a proxy receives a request over TCP, the proxy
|
||||
SHOULD forward the query over TCP and SHOULD NOT attempt the same
|
||||
query over UDP first.
|
||||
|
||||
4.4.2. Extension Mechanisms for DNS (EDNS0)
|
||||
|
||||
The Extension Mechanism for DNS [RFC2671] was introduced to allow the
|
||||
transport of larger DNS packets over UDP and also to allow for
|
||||
additional request and response flags.
|
||||
|
||||
A client may send an OPT Resource Record (OPT RR) in the Additional
|
||||
Section of a request to indicate that it supports a specific receive
|
||||
buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used
|
||||
by DNSSEC to indicate that DNSSEC-related RRs should be returned to
|
||||
the client.
|
||||
|
||||
However some proxies have been observed to either reject (with a
|
||||
FORMERR response code) or black-hole any packet containing an OPT RR.
|
||||
As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets.
|
||||
|
||||
4.4.3. IP Fragmentation
|
||||
|
||||
Support for UDP packet sizes exceeding the WAN MTU depends on the
|
||||
gateway's algorithm for handling fragmented IP packets. Several
|
||||
methods are possible:
|
||||
|
||||
1. fragments are dropped
|
||||
2. fragments are forwarded individually as they're received
|
||||
3. complete packets are reassembled on the gateway, and then re-
|
||||
fragmented (if necessary) as they're forwarded to the client
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 6]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
Method 1 above will cause compatibility problems with EDNS0 unless
|
||||
the DNS client is configured to advertise an EDNS0 buffer size
|
||||
limited to the WAN MTU less the size of the IP header. Note that RFC
|
||||
2671 does recommend that the path MTU should be taken into account
|
||||
when using EDNS0.
|
||||
|
||||
Also, whilst the EDNS0 specification allows for a buffer size of up
|
||||
to 65535 octets, most common DNS server implementations do not
|
||||
support a buffer size above 4096 octets.
|
||||
|
||||
Therefore (irrespective of which of the methods above is in use)
|
||||
proxies SHOULD be capable of forwarding UDP packets up to a payload
|
||||
size of at least 4096 octets.
|
||||
|
||||
NB: in theory IP fragmentation may also occur if the LAN MTU is
|
||||
smaller than the WAN MTU, although the author has not observed such a
|
||||
configuration in use on any residential broadband service.
|
||||
|
||||
4.5. Secret Key Transaction Authentication for DNS (TSIG)
|
||||
|
||||
[RFC2845] defines TSIG, which is a mechanism for authenticating DNS
|
||||
requests and responses at the packet level.
|
||||
|
||||
Any modifications made to the DNS portions of a TSIG-signed query or
|
||||
response packet (with the exception of the Query ID) will cause a
|
||||
TSIG authentication failure.
|
||||
|
||||
DNS proxies MUST implement Section 4.7 of [RFC2845] and either
|
||||
forward packets unchanged (as recommended above) or fully implement
|
||||
TSIG.
|
||||
|
||||
As per Section 4.3, DNS proxies MUST be capable of proxying packets
|
||||
containing TKEY [RFC2930] Resource Records.
|
||||
|
||||
NB: any DNS proxy (such as those commonly found in WiFi hotspot
|
||||
"walled gardens") which transparently intercepts all DNS queries, and
|
||||
which returns unsigned responses to signed queries, will also cause
|
||||
TSIG authentication failures.
|
||||
|
||||
|
||||
5. DHCP's Interaction with DNS
|
||||
|
||||
Whilst this document is primarily about DNS proxies, most consumers
|
||||
rely on DHCP [RFC2131] to obtain network configuration settings.
|
||||
Such settings include the client machine's IP address, subnet mask
|
||||
and default gateway, but also include DNS related settings.
|
||||
|
||||
It is therefore appropriate to examine how DHCP affects client DNS
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 7]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
configuration.
|
||||
|
||||
5.1. Domain Name Server (DHCP Option 6)
|
||||
|
||||
Most gateways default to supplying their own IP address in the DHCP
|
||||
"Domain Name Server" option [RFC2132]. The net result is that
|
||||
without explicit re-configuration many DNS clients will by default
|
||||
send queries to the gateway's DNS proxy. This is understandable
|
||||
behaviour given that the correct upstream settings are not usually
|
||||
known at boot time.
|
||||
|
||||
Most gateways learn their own DNS settings via values supplied by an
|
||||
ISP via DHCP or PPP over the WAN interface. However whilst many
|
||||
gateways do allow the device administrator to override those values,
|
||||
some gateways only use those supplied values to affect the proxy's
|
||||
own forwarding function, and do not offer these values via DHCP.
|
||||
|
||||
When using such a device the only way to avoid using the DNS proxy is
|
||||
to hard-code the required values in the client operating system.
|
||||
This may be acceptable for a desktop system but it is inappropriate
|
||||
for mobile devices which are regularly used on many different
|
||||
networks.
|
||||
|
||||
As per Section 3, end-users SHOULD be able to send their DNS queries
|
||||
directly to specified upstream resolvers, ideally without hard-coding
|
||||
those settings in their stub resolver.
|
||||
|
||||
It is therefore RECOMMENDED that gateways SHOULD support device
|
||||
administrator configuration of values for the "Domain Name Server"
|
||||
DHCP option.
|
||||
|
||||
5.2. Domain Name (DHCP Option 15)
|
||||
|
||||
A significant amount of traffic to the DNS Root Name Servers is for
|
||||
invalid top-level domain names, and some of that traffic can be
|
||||
attributed to particular equipment vendors whose firmware defaults
|
||||
this DHCP option to specific values.
|
||||
|
||||
Since no standard exists for a "local" scoped domain name suffix it
|
||||
is RECOMMENDED that the default value for this option SHOULD be
|
||||
empty, and that this option MUST NOT be sent to clients when no value
|
||||
is configured.
|
||||
|
||||
5.3. DHCP Leases
|
||||
|
||||
It is noted that some DHCP servers in broadband gateways by default
|
||||
offer their own IP address for the "Domain Name Server" option (as
|
||||
described above) but then automatically start offering the upstream
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 8]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
servers' addresses once they've been learnt over the WAN interface.
|
||||
|
||||
In general this behaviour is highly desirable, but the effect for the
|
||||
end-user is that the settings used depend on whether the DHCP lease
|
||||
was obtained before or after the WAN link was established.
|
||||
|
||||
If the DHCP lease is obtained whilst the WAN link is down then the
|
||||
DHCP client (and hence the DNS client) will not receive the correct
|
||||
values until the DHCP lease is renewed.
|
||||
|
||||
Whilst no specific recommendations are given here, vendors may wish
|
||||
to give consideration to the length of DHCP leases, and whether some
|
||||
mechanism for forcing a DHCP lease renewal might be appropriate.
|
||||
|
||||
Another possibility is that the learnt upstream values might be
|
||||
persisted in non-volatile memory such that on reboot the same values
|
||||
can be automatically offered via DHCP. However this does run the
|
||||
risk that incorrect values are initially offered if the device is
|
||||
moved or connected to another ISP.
|
||||
|
||||
Alternatively, the DHCP server might only issue very short (i.e. 60
|
||||
second) leases while the WAN link is down, only reverting to more
|
||||
typical lease lengths once the WAN link is up and the upstream DNS
|
||||
servers are known. Indeed with such a configuration it may be
|
||||
possible to avoid the need to implement a DNS proxy function in the
|
||||
broadband gateway at all.
|
||||
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
This document introduces no new protocols. However there are some
|
||||
security related recommendations for vendors that are listed here.
|
||||
|
||||
6.1. Forgery Resilience
|
||||
|
||||
Whilst DNS proxies are not usually full-feature resolvers they
|
||||
nevertheless share some characteristics with them.
|
||||
|
||||
Notwithstanding the recommendations above about transparency many DNS
|
||||
proxies are observed to pick a new Query ID for outbound requests to
|
||||
ensure that responses are directed to the correct client.
|
||||
|
||||
NB: Changing the Query ID is acceptable and compatible with proxying
|
||||
TSIG-signed packets since the TSIG signature calculation is based on
|
||||
the original message ID which is carried in the TSIG RR.
|
||||
|
||||
It has been standard guidance for many years that each DNS query
|
||||
should use a randomly generated Query ID. However many proxies have
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 9]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
been observed picking sequential Query IDs for successive requests.
|
||||
|
||||
It is strongly RECOMMENDED that DNS proxies follow the relevant
|
||||
recommendations in [RFC5452], particularly those in Section 9.2
|
||||
relating to randomisation of Query IDs and source ports. This also
|
||||
applies to source port selection within any NAT function.
|
||||
|
||||
If a DNS proxy is running on a broadband gateway with NAT that is
|
||||
compliant with [RFC4787] then it SHOULD also follow the
|
||||
recommendations in Section 10 of [RFC5452] concerning how long DNS
|
||||
state is kept.
|
||||
|
||||
6.2. Interface Binding
|
||||
|
||||
Some gateways have been observed to have their DNS proxy listening on
|
||||
both internal (LAN) and external (WAN) interfaces. In this
|
||||
configuration it is possible for the proxy to be used to mount
|
||||
reflector attacks as described in [RFC5358].
|
||||
|
||||
The DNS proxy in a gateway SHOULD NOT by default be accessible from
|
||||
the WAN interfaces of the device.
|
||||
|
||||
6.3. Packet Filtering
|
||||
|
||||
The Transparency and Robustness Principles are not entirely
|
||||
compatible with the deep packet inspection features of security
|
||||
appliances such as firewalls which are intended to protect systems on
|
||||
the inside of a network from rogue traffic.
|
||||
|
||||
However a clear distinction may be made between traffic that is
|
||||
intrinsically malformed and that which merely contains unexpected
|
||||
data.
|
||||
|
||||
Examples of malformed packets which MAY be dropped include:
|
||||
|
||||
o invalid compression pointers (i.e. those that point outside of the
|
||||
current packet, or which might cause a parsing loop).
|
||||
o incorrect counts for the Question, Answer, Authority and
|
||||
Additional Sections (although care should be taken where
|
||||
truncation is a possibility).
|
||||
|
||||
Since dropped packets will cause the client to repeatedly retransmit
|
||||
the original request, it is RECOMMENDED that proxies SHOULD instead
|
||||
return a suitable DNS error response to the client (i.e. SERVFAIL)
|
||||
instead of dropping the packet completely.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 10]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
This document requests no IANA actions.
|
||||
|
||||
|
||||
8. Change Log
|
||||
|
||||
NB: to be removed by the RFC Editor before publication.
|
||||
|
||||
draft-ietf-dnsproxy-05
|
||||
Removed specific reference to 28 byte IP headers (from Mark
|
||||
Andrews)
|
||||
|
||||
draft-ietf-dnsproxy-04 - post WGLC
|
||||
Introduction expanded
|
||||
Section 5.2 - changed SHOULD to MUST
|
||||
Section 4.5 - changed SHOULD to MUST (Alex Bligh)
|
||||
Editorial nits (from Andrew Sullivan, Alfred Hones)
|
||||
Clarificaton on end-user vs device administrator (Alan Barrett,
|
||||
Paul Selkirk)
|
||||
|
||||
draft-ietf-dnsproxy-03
|
||||
Editorial nits and mention of LAN MTU (from Alex Bligh)
|
||||
|
||||
draft-ietf-dnsproxy-02
|
||||
Changed "router" to "gateway" throughout (David Oran)
|
||||
Updated forgery resilience reference
|
||||
Elaboration on bypassability (from Nicholas W.)
|
||||
Elaboration on NAT source port randomisation (from Nicholas W.)
|
||||
Mention of using short DHCP leases while the WAN link is down
|
||||
(from Ralph Droms)
|
||||
Further clarification on permissibility of altering QID when using
|
||||
TSIG
|
||||
|
||||
draft-ietf-dnsproxy-01
|
||||
Strengthened recommendations about truncation (from Shane Kerr)
|
||||
New TSIG text (with help from Olafur)
|
||||
Additional forgery resilience text (from Olafur)
|
||||
Compression support (from Olafur)
|
||||
Correction of text re: QID changes and compatibility with TSIG
|
||||
|
||||
draft-ietf-dnsproxy-00
|
||||
Changed recommended DPI error to SERVFAIL (from Jelte)
|
||||
Changed example for invalid compression pointers (from Wouter).
|
||||
Note about TSIG implications of changing Query ID (from Wouter).
|
||||
Clarified TC-bit text (from Wouter)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 11]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
Extra text about proxy bypass (Nicholas W.)
|
||||
|
||||
draft-bellis-dnsproxy-00
|
||||
Initial draft
|
||||
|
||||
|
||||
9. Acknowledgements
|
||||
|
||||
The author would particularly like to acknowledge the assistance of
|
||||
Lisa Phifer of Core Competence. In addition the author is grateful
|
||||
for the feedback from the members of the DNSEXT Working Group.
|
||||
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
|
||||
RFC 793, September 1981.
|
||||
|
||||
[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.
|
||||
|
||||
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
|
||||
RFC 2131, March 1997.
|
||||
|
||||
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
|
||||
Extensions", RFC 2132, March 1997.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
|
||||
RFC 2671, August 1999.
|
||||
|
||||
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
|
||||
Wellington, "Secret Key Transaction Authentication for DNS
|
||||
(TSIG)", RFC 2845, May 2000.
|
||||
|
||||
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
|
||||
RR)", RFC 2930, September 2000.
|
||||
|
||||
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
|
||||
(RR) Types", RFC 3597, September 2003.
|
||||
|
||||
|
||||
|
||||
|
||||
Bellis Expires October 25, 2009 [Page 12]
|
||||
|
||||
Internet-Draft DNS Proxy Implementation Guidelines April 2009
|
||||
|
||||
|
||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security
|
||||
Extensions", RFC 4035, March 2005.
|
||||
|
||||
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
|
||||
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
|
||||
RFC 4787, January 2007.
|
||||
|
||||
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
|
||||
Nameservers in Reflector Attacks", BCP 140, RFC 5358,
|
||||
October 2008.
|
||||
|
||||
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
|
||||
Resilient against Forged Answers", RFC 5452, January 2009.
|
||||
|
||||
10.2. Informative References
|
||||
|
||||
[DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
|
||||
Routers", February 2008,
|
||||
<http://www.iis.se/docs/Routertester_en.pdf>.
|
||||
|
||||
[SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
|
||||
Broadband Routers and Firewalls", September 2008,
|
||||
<http://www.icann.org/committees/security/sac035.pdf>.
|
||||
|
||||
|
||||
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 October 25, 2009 [Page 13]
|
||||
|
||||
@@ -1,672 +0,0 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Weiler
|
||||
Internet-Draft SPARTA, Inc.
|
||||
Updates: 4033, 4034, 4035, 5155 D. Blacka
|
||||
(if approved) VeriSign, Inc.
|
||||
Intended status: Standards Track September 5, 2009
|
||||
Expires: March 9, 2010
|
||||
|
||||
|
||||
Clarifications and Implementation Notes for DNSSECbis
|
||||
draft-ietf-dnsext-dnssec-bis-updates-09
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This Internet-Draft is submitted to IETF in full conformance with the
|
||||
provisions of BCP 78 and BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on March 9, 2010.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2009 IETF Trust and the persons identified as the
|
||||
document authors. All rights reserved.
|
||||
|
||||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||||
Provisions Relating to IETF Documents in effect on the date of
|
||||
publication of this document (http://trustee.ietf.org/license-info).
|
||||
Please review these documents carefully, as they describe your rights
|
||||
and restrictions with respect to this document.
|
||||
|
||||
Abstract
|
||||
|
||||
This document is a collection of technical clarifications to the
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 1]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
DNSSECbis document set. It is meant to serve as a resource to
|
||||
implementors as well as a repository of DNSSECbis errata.
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3
|
||||
1.1. Structure of this Document . . . . . . . . . . . . . . . . 3
|
||||
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3
|
||||
2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 3
|
||||
3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4
|
||||
3.2. Validating Responses to an ANY Query . . . . . . . . . . . 4
|
||||
3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5
|
||||
4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
|
||||
4.1. Errors in Canonical Form Type Code List . . . . . . . . . 5
|
||||
4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
|
||||
4.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
|
||||
4.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7
|
||||
4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
|
||||
4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7
|
||||
4.7. Setting the AD bit on Replies . . . . . . . . . . . . . . 7
|
||||
4.8. Setting the CD bit on Requests . . . . . . . . . . . . . . 8
|
||||
4.9. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8
|
||||
5. Minor Corrections and Clarifications . . . . . . . . . . . . . 8
|
||||
5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 8
|
||||
5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 9
|
||||
5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 9
|
||||
5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 9
|
||||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
|
||||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
|
||||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
|
||||
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
|
||||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 2]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
1. Introduction and Terminology
|
||||
|
||||
This document lists some additions, clarifications and corrections to
|
||||
the core DNSSECbis specification, as originally described in
|
||||
[RFC4033], [RFC4034], and [RFC4035].
|
||||
|
||||
It is intended to serve as a resource for implementors and as a
|
||||
repository of items that need to be addressed when advancing the
|
||||
DNSSECbis documents from Proposed Standard to Draft Standard.
|
||||
|
||||
1.1. Structure of this Document
|
||||
|
||||
The clarifications to DNSSECbis are sorted according to their
|
||||
importance, starting with ones which could, if ignored, lead to
|
||||
security problems and progressing down to clarifications that are
|
||||
expected to have little operational impact.
|
||||
|
||||
1.2. Terminology
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
|
||||
2. Important Additions to DNSSSECbis
|
||||
|
||||
This section updates the set of core DNSSEC protocol documents
|
||||
originally specified in Section 10 of [RFC4033].
|
||||
|
||||
2.1. NSEC3 Support
|
||||
|
||||
[RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
|
||||
records for hashed denial of existence. Validator implementations
|
||||
are strongly encouraged to include support for NSEC3 because a number
|
||||
of highly visible zones are expected to use it. Validators that do
|
||||
not support validation of responses using NSEC3 will likely be
|
||||
hampered in validating large portions of the DNS space.
|
||||
|
||||
[RFC5155] should be considered part of the DNS Security Document
|
||||
Family as described by [RFC4033], Section 10.
|
||||
|
||||
2.2. SHA-256 Support
|
||||
|
||||
[RFC4509] describes the use of SHA-256 as a digest algorithm for use
|
||||
with Delegation Signer (DS) RRs. [I-D.ietf-dnsext-dnssec-rsasha256]
|
||||
describes the use of the RSASHA256 algorithm for use in DNSKEY and
|
||||
RRSIG RRs. Validator implementations are strongly encouraged to
|
||||
include support for this algorithm for DS, DNSKEY, and RRSIG records.
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 3]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be
|
||||
considered part of the DNS Security Document Family as described by
|
||||
[RFC4033], Section 10.
|
||||
|
||||
|
||||
3. Security Concerns
|
||||
|
||||
This section provides clarifications that, if overlooked, could lead
|
||||
to security issues.
|
||||
|
||||
3.1. Clarifications on Non-Existence Proofs
|
||||
|
||||
[RFC4035] Section 5.4 under-specifies the algorithm for checking non-
|
||||
existence proofs. In particular, the algorithm as presented would
|
||||
incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove
|
||||
the non-existence of RRs in the child zone.
|
||||
|
||||
An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
|
||||
|
||||
o the NS bit set,
|
||||
o the SOA bit clear, and
|
||||
o a signer field that is shorter than the owner name of the NSEC RR,
|
||||
or the original owner name for the NSEC3 RR.
|
||||
|
||||
Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non-
|
||||
existence of any RRs below that zone cut, which include all RRs at
|
||||
that (original) owner name other than DS RRs, and all RRs below that
|
||||
owner name regardless of type.
|
||||
|
||||
Similarly, the algorithm would also allow an NSEC RR at the same
|
||||
owner name as a DNAME RR, or an NSEC3 RR at the same original owner
|
||||
name as a DNAME, to prove the non-existence of names beneath that
|
||||
DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
|
||||
to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
|
||||
(original) owner name.
|
||||
|
||||
3.2. Validating Responses to an ANY Query
|
||||
|
||||
[RFC4035] does not address how to validate responses when QTYPE=*.
|
||||
As described in Section 6.2.2 of [RFC1034], a proper response to
|
||||
QTYPE=* may include a subset of the RRsets at a given name. That is,
|
||||
it is not necessary to include all RRsets at the QNAME in the
|
||||
response.
|
||||
|
||||
When validating a response to QTYPE=*, all received RRsets that match
|
||||
QNAME and QCLASS MUST be validated. If any of those RRsets fail
|
||||
validation, the answer is considered Bogus. If there are no RRsets
|
||||
matching QNAME and QCLASS, that fact MUST be validated according to
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 4]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
the rules in [RFC4035] Section 5.4 (as clarified in this document).
|
||||
To be clear, a validator must not expect to receive all records at
|
||||
the QNAME in response to QTYPE=*.
|
||||
|
||||
3.3. Check for CNAME
|
||||
|
||||
Section 5 of [RFC4035] says little about validating responses based
|
||||
on (or that should be based on) CNAMEs. When validating a NOERROR/
|
||||
NODATA response, validators MUST check the CNAME bit in the matching
|
||||
NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
|
||||
type. Without this check, an attacker could successfully transform a
|
||||
positive CNAME response into a NOERROR/NODATA response.
|
||||
|
||||
3.4. Insecure Delegation Proofs
|
||||
|
||||
[RFC4035] Section 5.2 specifies that a validator, when proving a
|
||||
delegation is not secure, needs to check for the absence of the DS
|
||||
and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also
|
||||
needs to check for the presence of the NS bit in the matching NSEC
|
||||
(or NSEC3) RR (proving that there is, indeed, a delegation), or
|
||||
alternately make sure that the delegation is covered by an NSEC3 RR
|
||||
with the Opt-Out flag set. If this is not checked, spoofed unsigned
|
||||
delegations might be used to claim that an existing signed record is
|
||||
not signed.
|
||||
|
||||
|
||||
4. Interoperability Concerns
|
||||
|
||||
4.1. Errors in Canonical Form Type Code List
|
||||
|
||||
When canonicalizing DNS names, DNS names in the RDATA section of NSEC
|
||||
and RRSIG resource records are not downcased.
|
||||
|
||||
[RFC4034] Section 6.2 item 3 has a list of resource record types for
|
||||
which DNS names in the RDATA are downcased for purposes of DNSSEC
|
||||
canonical form (for both ordering and signing). That list
|
||||
erroneously contains NSEC and RRSIG. According to [RFC3755], DNS
|
||||
names in the RDATA of NSEC and RRSIG should not be downcased.
|
||||
|
||||
The same section also erroneously lists HINFO, and twice at that.
|
||||
Since HINFO records contain no domain names, they are not subject to
|
||||
downcasing.
|
||||
|
||||
4.2. Unknown DS Message Digest Algorithms
|
||||
|
||||
Section 5.2 of [RFC4035] includes rules for how to handle delegations
|
||||
to zones that are signed with entirely unsupported public key
|
||||
algorithms, as indicated by the key algorithms shown in those zone's
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 5]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
DS RRsets. It does not explicitly address how to handle DS records
|
||||
that use unsupported message digest algorithms. In brief, DS records
|
||||
using unknown or unsupported message digest algorithms MUST be
|
||||
treated the same way as DS records referring to DNSKEY RRs of unknown
|
||||
or unsupported public key algorithms.
|
||||
|
||||
The existing text says:
|
||||
|
||||
If the validator does not support any of the algorithms listed in
|
||||
an authenticated DS RRset, then the resolver has no supported
|
||||
authentication path leading from the parent to the child. The
|
||||
resolver should treat this case as it would the case of an
|
||||
authenticated NSEC RRset proving that no DS RRset exists, as
|
||||
described above.
|
||||
|
||||
To paraphrase the above, when determining the security status of a
|
||||
zone, a validator disregards any DS records listing unknown or
|
||||
unsupported algorithms. If none are left, the zone is treated as if
|
||||
it were unsigned.
|
||||
|
||||
Modified to consider DS message digest algorithms, a validator also
|
||||
disregards any DS records using unknown or unsupported message digest
|
||||
algorithms.
|
||||
|
||||
4.3. Private Algorithms
|
||||
|
||||
As discussed above, section 5.2 of [RFC4035] requires that validators
|
||||
make decisions about the security status of zones based on the public
|
||||
key algorithms shown in the DS records for those zones. In the case
|
||||
of private algorithms, as described in [RFC4034] Appendix A.1.1, the
|
||||
eight-bit algorithm field in the DS RR is not conclusive about what
|
||||
algorithm(s) is actually in use.
|
||||
|
||||
If no private algorithms appear in the DS set or if any supported
|
||||
algorithm appears in the DS set, no special processing will be
|
||||
needed. In the remaining cases, the security status of the zone
|
||||
depends on whether or not the resolver supports any of the private
|
||||
algorithms in use (provided that these DS records use supported hash
|
||||
functions, as discussed in Section 4.2). In these cases, the
|
||||
resolver MUST retrieve the corresponding DNSKEY for each private
|
||||
algorithm DS record and examine the public key field to determine the
|
||||
algorithm in use. The security-aware resolver MUST ensure that the
|
||||
hash of the DNSKEY RR's owner name and RDATA matches the digest in
|
||||
the DS RR. If they do not match, and no other DS establishes that
|
||||
the zone is secure, the referral should be considered Bogus data, as
|
||||
discussed in [RFC4035].
|
||||
|
||||
This clarification facilitates the broader use of private algorithms,
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 6]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
as suggested by [RFC4955].
|
||||
|
||||
4.4. Caution About Local Policy and Multiple RRSIGs
|
||||
|
||||
When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
|
||||
suggests that "the local resolver security policy determines whether
|
||||
the resolver also has to test these RRSIG RRs and how to resolve
|
||||
conflicts if these RRSIG RRs lead to differing results." In most
|
||||
cases, a resolver would be well advised to accept any valid RRSIG as
|
||||
sufficient. If the first RRSIG tested fails validation, a resolver
|
||||
would be well advised to try others, giving a successful validation
|
||||
result if any can be validated and giving a failure only if all
|
||||
RRSIGs fail validation.
|
||||
|
||||
If a resolver adopts a more restrictive policy, there's a danger that
|
||||
properly-signed data might unnecessarily fail validation, perhaps
|
||||
because of cache timing issues. Furthermore, certain zone management
|
||||
techniques, like the Double Signature Zone-signing Key Rollover
|
||||
method described in section 4.2.1.2 of [RFC4641] might not work
|
||||
reliably.
|
||||
|
||||
4.5. Key Tag Calculation
|
||||
|
||||
[RFC4034] Appendix B.1 incorrectly defines the Key Tag field
|
||||
calculation for algorithm 1. It correctly says that the Key Tag is
|
||||
the most significant 16 of the least significant 24 bits of the
|
||||
public key modulus. However, [RFC4034] then goes on to incorrectly
|
||||
say that this is 4th to last and 3rd to last octets of the public key
|
||||
modulus. It is, in fact, the 3rd to last and 2nd to last octets.
|
||||
|
||||
4.6. Setting the DO Bit on Replies
|
||||
|
||||
[RFC4035] does not provide any instructions to servers as to how to
|
||||
set the DO bit. Some authoritative server implementations have
|
||||
chosen to copy the DO bit settings from the incoming query to the
|
||||
outgoing response. Others have chosen to never set the DO bit in
|
||||
responses. Either behavior is permitted. To be clear, in replies to
|
||||
queries with the DO-bit set servers may or may not set the DO bit.
|
||||
|
||||
4.7. Setting the AD bit on Replies
|
||||
|
||||
Section 3.2.3 of [RFC4035] describes under which conditions a
|
||||
validating resolver should set or clear the AD bit in a response. In
|
||||
order to protect legacy stub resolvers and middleboxes, validating
|
||||
resolvers SHOULD only set the AD bit when a response both meets the
|
||||
conditions listed in RFC 4035, section 3.2.3, and the request
|
||||
contained either a set DO bit or a set AD bit.
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 7]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
Note that the use of the AD bit in the query was previously
|
||||
undefined. This document defines it as a signal indicating that the
|
||||
requester understands and is interested in the value of the AD bit in
|
||||
the response. This allows a requestor to indicate that it
|
||||
understands the AD bit without also requesting DNSSEC data via the DO
|
||||
bit.
|
||||
|
||||
4.8. Setting the CD bit on Requests
|
||||
|
||||
When processing a request with the CD bit set, the resolver MUST set
|
||||
the CD bit on its upstream queries.
|
||||
|
||||
4.9. Nested Trust Anchors
|
||||
|
||||
A DNSSEC validator may be configured such that, for a given response,
|
||||
more than one trust anchor could be used to validate the chain of
|
||||
trust to the response zone. For example, imagine a validator
|
||||
configured with trust anchors for "example." and "zone.example."
|
||||
When the validator is asked to validate a response to
|
||||
"www.sub.zone.example.", either trust anchor could apply.
|
||||
|
||||
When presented with this situation, DNSSEC validators SHOULD try all
|
||||
applicable trust anchors until one succeeds.
|
||||
|
||||
There are some scenarios where different behaviors, such as choosing
|
||||
the trust anchor closest to the QNAME of the response, may be
|
||||
desired. A DNSSEC validator MAY enable such behaviors as
|
||||
configurable overrides.
|
||||
|
||||
|
||||
5. Minor Corrections and Clarifications
|
||||
|
||||
5.1. Finding Zone Cuts
|
||||
|
||||
Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
|
||||
for a parent zone. To do that, a resolver may first need to apply
|
||||
special rules to discover what those servers are.
|
||||
|
||||
As explained in Section 3.1.4.1 of [RFC4035], security-aware name
|
||||
servers need to apply special processing rules to handle the DS RR,
|
||||
and in some situations the resolver may also need to apply special
|
||||
rules to locate the name servers for the parent zone if the resolver
|
||||
does not already have the parent's NS RRset. Section 4.2 of
|
||||
[RFC4035] specifies a mechanism for doing that.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 8]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
5.2. Clarifications on DNSKEY Usage
|
||||
|
||||
Questions of the form "can I use a different DNSKEY for signing this
|
||||
RRset" have occasionally arisen.
|
||||
|
||||
The short answer is "yes, absolutely". You can even use a different
|
||||
DNSKEY for each RRset in a zone, subject only to practical limits on
|
||||
the size of the DNSKEY RRset. However, be aware that there is no way
|
||||
to tell resolvers what a particularly DNSKEY is supposed to be used
|
||||
for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
|
||||
authenticate any RRset in the zone. For example, if a weaker or less
|
||||
trusted DNSKEY is being used to authenticate NSEC RRsets or all
|
||||
dynamically updated records, that same DNSKEY can also be used to
|
||||
sign any other RRsets from the zone.
|
||||
|
||||
Furthermore, note that the SEP bit setting has no effect on how a
|
||||
DNSKEY may be used -- the validation process is specifically
|
||||
prohibited from using that bit by [RFC4034] section 2.1.2. It is
|
||||
possible to use a DNSKEY without the SEP bit set as the sole secure
|
||||
entry point to the zone, yet use a DNSKEY with the SEP bit set to
|
||||
sign all RRsets in the zone (other than the DNSKEY RRset). It's also
|
||||
possible to use a single DNSKEY, with or without the SEP bit set, to
|
||||
sign the entire zone, including the DNSKEY RRset itself.
|
||||
|
||||
5.3. Errors in Examples
|
||||
|
||||
The text in [RFC4035] Section C.1 refers to the examples in B.1 as
|
||||
"x.w.example.com" while B.1 uses "x.w.example". This is painfully
|
||||
obvious in the second paragraph where it states that the RRSIG labels
|
||||
field value of 3 indicates that the answer was not the result of
|
||||
wildcard expansion. This is true for "x.w.example" but not for
|
||||
"x.w.example.com", which of course has a label count of 4
|
||||
(antithetically, a label count of 3 would imply the answer was the
|
||||
result of a wildcard expansion).
|
||||
|
||||
The first paragraph of [RFC4035] Section C.6 also has a minor error:
|
||||
the reference to "a.z.w.w.example" should instead be "a.z.w.example",
|
||||
as in the previous line.
|
||||
|
||||
5.4. Errors in RFC 5155
|
||||
|
||||
A NSEC3 record that matches an Empty Non-Terminal effectively has no
|
||||
type associated with it. This NSEC3 record has an empty type bit
|
||||
map. Section 3.2.1 of [RFC5155] contains the statement:
|
||||
|
||||
Blocks with no types present MUST NOT be included.
|
||||
|
||||
However, the same section contains a regular expression:
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 9]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
|
||||
|
||||
The plus sign in the regular expression indicates that there is one
|
||||
or more of the preceding element. This means that there must be at
|
||||
least one window block. If this window block has no types, it
|
||||
contradicts with the first statement. Therefore, the correct text in
|
||||
RFC 5155 3.2.1 should be:
|
||||
|
||||
Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
|
||||
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
This document specifies no IANA Actions.
|
||||
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
This document adds two cryptographic features to the core DNSSEC
|
||||
protocol. Additionally, it addresses some ambiguities and omissions
|
||||
in the core DNSSEC documents that, if not recognized and addressed in
|
||||
implementations, could lead to security failures. In particular, the
|
||||
validation algorithm clarifications in Section 3 are critical for
|
||||
preserving the security properties DNSSEC offers. Furthermore,
|
||||
failure to address some of the interoperability concerns in Section 4
|
||||
could limit the ability to later change or expand DNSSEC, including
|
||||
adding new algorithms.
|
||||
|
||||
|
||||
8. References
|
||||
|
||||
8.1. Normative References
|
||||
|
||||
[I-D.ietf-dnsext-dnssec-rsasha256]
|
||||
Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
|
||||
and RRSIG Resource Records for DNSSEC",
|
||||
draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress),
|
||||
June 2009.
|
||||
|
||||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
||||
RFC 1034, STD 13, November 1987.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", RFC 2119, BCP 14, March 1997.
|
||||
|
||||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements",
|
||||
RFC 4033, March 2005.
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 10]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions",
|
||||
RFC 4034, March 2005.
|
||||
|
||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security
|
||||
Extensions", RFC 4035, March 2005.
|
||||
|
||||
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
|
||||
(DS) Resource Records (RRs)", RFC 4509, May 2006.
|
||||
|
||||
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
|
||||
Security (DNSSEC) Hashed Authenticated Denial of
|
||||
Existence", RFC 5155, March 2008.
|
||||
|
||||
8.2. Informative References
|
||||
|
||||
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
|
||||
Signer (DS)", RFC 3755, May 2004.
|
||||
|
||||
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
|
||||
RFC 4641, September 2006.
|
||||
|
||||
[RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
|
||||
July 2007.
|
||||
|
||||
|
||||
Appendix A. Acknowledgments
|
||||
|
||||
The editors would like the thank Rob Austein for his previous work as
|
||||
an editor of this document.
|
||||
|
||||
The editors are extremely grateful to those who, in addition to
|
||||
finding errors and omissions in the DNSSECbis document set, have
|
||||
provided text suitable for inclusion in this document.
|
||||
|
||||
The lack of specificity about handling private algorithms, as
|
||||
described in Section 4.3, and the lack of specificity in handling ANY
|
||||
queries, as described in Section 3.2, were discovered by David
|
||||
Blacka.
|
||||
|
||||
The error in algorithm 1 key tag calculation, as described in
|
||||
Section 4.5, was found by Abhijit Hayatnagarkar. Donald Eastlake
|
||||
contributed text for Section 4.5.
|
||||
|
||||
The bug relating to delegation NSEC RR's in Section 3.1 was found by
|
||||
Roy Badami. Roy Arends found the related problem with DNAME.
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 11]
|
||||
|
||||
Internet-Draft DNSSECbis Implementation Notes September 2009
|
||||
|
||||
|
||||
The errors in the [RFC4035] examples were found by Roy Arends, who
|
||||
also contributed text for Section 5.3 of this document.
|
||||
|
||||
The editors would like to thank Ed Lewis, Danny Mayer, Olafur
|
||||
Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive
|
||||
comments on the text of this document.
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Samuel Weiler
|
||||
SPARTA, Inc.
|
||||
7110 Samuel Morse Drive
|
||||
Columbia, Maryland 21046
|
||||
US
|
||||
|
||||
Email: weiler@tislabs.com
|
||||
|
||||
|
||||
David Blacka
|
||||
VeriSign, Inc.
|
||||
21345 Ridgetop Circle
|
||||
Dulles, VA 20166
|
||||
US
|
||||
|
||||
Email: davidb@verisign.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Blacka Expires March 9, 2010 [Page 12]
|
||||
|
||||
@@ -1,840 +0,0 @@
|
||||
|
||||
|
||||
|
||||
DNSEXT D. Blacka
|
||||
Internet-Draft VeriSign, Inc.
|
||||
Intended status: Standards Track April 7, 2006
|
||||
Expires: October 9, 2006
|
||||
|
||||
|
||||
DNSSEC Experiments
|
||||
draft-ietf-dnsext-dnssec-experiments-03
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of 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 October 9, 2006.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 1]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes a methodology for deploying alternate, non-
|
||||
backwards-compatible, DNSSEC methodologies in an experimental fashion
|
||||
without disrupting the deployment of standard DNSSEC.
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
|
||||
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8
|
||||
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9
|
||||
7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
|
||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
|
||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
|
||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
|
||||
10.2. Informative References . . . . . . . . . . . . . . . . . 13
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 15
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 2]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
1. Definitions and Terminology
|
||||
|
||||
Throughout this document, familiarity with the DNS system (RFC 1035
|
||||
[5]) and the DNS security extensions ([2], [3], and [4] is assumed.
|
||||
|
||||
The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119 [1].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 3]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
2. Overview
|
||||
|
||||
Historically, experimentation with DNSSEC alternatives has been a
|
||||
problematic endeavor. There has typically been a desire to both
|
||||
introduce non-backwards-compatible changes to DNSSEC and to try these
|
||||
changes on real zones in the public DNS. This creates a problem when
|
||||
the change to DNSSEC would make all or part of the zone using those
|
||||
changes appear bogus (bad) or otherwise broken to existing security-
|
||||
aware resolvers.
|
||||
|
||||
This document describes a standard methodology for setting up DNSSEC
|
||||
experiments. This methodology addresses the issue of co-existence
|
||||
with standard DNSSEC and DNS by using unknown algorithm identifiers
|
||||
to hide the experimental DNSSEC protocol modifications from standard
|
||||
security-aware resolvers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 4]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
3. Experiments
|
||||
|
||||
When discussing DNSSEC experiments, it is necessary to classify these
|
||||
experiments into two broad categories:
|
||||
|
||||
Backwards-Compatible: describes experimental changes that, while not
|
||||
strictly adhering to the DNSSEC standard, are nonetheless
|
||||
interoperable with clients and servers that do implement the
|
||||
DNSSEC standard.
|
||||
|
||||
Non-Backwards-Compatible: describes experiments that would cause a
|
||||
standard security-aware resolver to (incorrectly) determine that
|
||||
all or part of a zone is bogus, or to otherwise not interoperate
|
||||
with standard DNSSEC clients and servers.
|
||||
|
||||
Not included in these terms are experiments with the core DNS
|
||||
protocol itself.
|
||||
|
||||
The methodology described in this document is not necessary for
|
||||
backwards-compatible experiments, although it certainly may be used
|
||||
if desired.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 5]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
4. Method
|
||||
|
||||
The core of the methodology is the use of strictly unknown algorithm
|
||||
identifiers when signing the experimental zone, and more importantly,
|
||||
having only unknown algorithm identifiers in the DS records for the
|
||||
delegation to the zone at the parent.
|
||||
|
||||
This technique works because of the way DNSSEC-compliant validators
|
||||
are expected to work in the presence of a DS set with only unknown
|
||||
algorithm identifiers. From [4], Section 5.2:
|
||||
|
||||
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.
|
||||
|
||||
And further:
|
||||
|
||||
If the resolver does not support any of the algorithms listed in
|
||||
an authenticated DS RRset, then the resolver will not be able to
|
||||
verify the authentication path to the child zone. In this case,
|
||||
the resolver SHOULD treat the child zone as if it were unsigned.
|
||||
|
||||
While this behavior isn't strictly mandatory (as marked by MUST), it
|
||||
is likely that a validator would implement this behavior, or, more to
|
||||
the point, it would handle this situation in a safe way (see below
|
||||
(Section 6).)
|
||||
|
||||
Because we are talking about experiments, it is RECOMMENDED that
|
||||
private algorithm numbers be used (see [3], appendix A.1.1. Note
|
||||
that secure handling of private algorithms requires special handing
|
||||
by the validator logic. See [6] for further details.) Normally,
|
||||
instead of actually inventing new signing algorithms, the recommended
|
||||
path is to create alternate algorithm identifiers that are aliases
|
||||
for the existing, known algorithms. While, strictly speaking, it is
|
||||
only necessary to create an alternate identifier for the mandatory
|
||||
algorithms, it is suggested that all optional defined algorithms be
|
||||
aliased as well.
|
||||
|
||||
It is RECOMMENDED that for a particular DNSSEC experiment, a
|
||||
particular domain name base is chosen for all new algorithms, then
|
||||
the algorithm number (or name) is prepended to it. For example, for
|
||||
experiment A, the base name of "dnssec-experiment-a.example.com" is
|
||||
chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
|
||||
defined to be "3.dnssec-experiment-a.example.com" and
|
||||
"5.dnssec-experiment-a.example.com". However, any unique identifier
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 6]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
will suffice.
|
||||
|
||||
Using this method, resolvers (or, more specifically, DNSSEC
|
||||
validators) essentially indicate their ability to understand the
|
||||
DNSSEC experiment's semantics by understanding what the new algorithm
|
||||
identifiers signify.
|
||||
|
||||
This method creates two classes of security-aware servers and
|
||||
resolvers: servers and resolvers that are aware of the experiment
|
||||
(and thus recognize the experiment's algorithm identifiers and
|
||||
experimental semantics), and servers and resolvers that are unaware
|
||||
of the experiment.
|
||||
|
||||
This method also precludes any zone from being both in an experiment
|
||||
and in a classic DNSSEC island of security. That is, a zone is
|
||||
either in an experiment and only experimentally validatable, or it is
|
||||
not.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 7]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
5. Defining an Experiment
|
||||
|
||||
The DNSSEC experiment MUST define the particular set of (previously
|
||||
unknown) algorithm identifiers that identify the experiment, and
|
||||
define what each unknown algorithm identifier means. Typically,
|
||||
unless the experiment is actually experimenting with a new DNSSEC
|
||||
algorithm, this will be a mapping of private algorithm identifiers to
|
||||
existing, known algorithms.
|
||||
|
||||
Normally the experiment will choose a DNS name as the algorithm
|
||||
identifier base. This DNS name SHOULD be under the control of the
|
||||
authors of the experiment. Then the experiment will define a mapping
|
||||
between known mandatory and optional algorithms into this private
|
||||
algorithm identifier space. Alternately, the experiment MAY use the
|
||||
OID private algorithm space instead (using algorithm number 254), or
|
||||
MAY choose non-private algorithm numbers, although this would require
|
||||
an IANA allocation.
|
||||
|
||||
For example, an experiment might specify in its description the DNS
|
||||
name "dnssec-experiment-a.example.com" as the base name, and declare
|
||||
that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
|
||||
algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
|
||||
alias of DNSSEC algorithm 5 (RSASHA1).
|
||||
|
||||
Resolvers MUST only recognize the experiment's semantics when present
|
||||
in a zone signed by one or more of these algorithm identifiers. This
|
||||
is necessary to isolate the semantics of one experiment from any
|
||||
others that the resolver might understand.
|
||||
|
||||
In general, resolvers involved in the experiment are expected to
|
||||
understand both standard DNSSEC and the defined experimental DNSSEC
|
||||
protocol, although this isn't required.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 8]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
6. Considerations
|
||||
|
||||
There are a number of considerations with using this methodology.
|
||||
|
||||
1. Under some circumstances, it may be that the experiment will not
|
||||
be sufficiently masked by this technique and may cause resolution
|
||||
problem for resolvers not aware of the experiment. For instance,
|
||||
the resolver may look at a non-validatable response and conclude
|
||||
that the response is bogus, either due to local policy or
|
||||
implementation details. This is not expected to be a common
|
||||
case, however.
|
||||
|
||||
2. It will not be possible for security-aware resolvers unaware of
|
||||
the experiment to build a chain of trust through an experimental
|
||||
zone.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 9]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
7. Use in Non-Experiments
|
||||
|
||||
This general methodology MAY be used for non-backwards compatible
|
||||
DNSSEC protocol changes that start out as or become standards. In
|
||||
this case:
|
||||
|
||||
o The protocol change SHOULD use public IANA allocated algorithm
|
||||
identifiers instead of private algorithm identifiers. This will
|
||||
help identify the protocol change as a standard, rather than an
|
||||
experiment.
|
||||
|
||||
o Resolvers MAY recognize the protocol change in zones not signed
|
||||
(or not solely signed) using the new algorithm identifiers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 10]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
Zones using this methodology will be considered insecure by all
|
||||
resolvers except those aware of the experiment. It is not generally
|
||||
possible to create a secure delegation from an experimental zone that
|
||||
will be followed by resolvers unaware of the experiment.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 11]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
9. IANA Considerations
|
||||
|
||||
This document has no IANA actions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 12]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033,
|
||||
March 2005.
|
||||
|
||||
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
[4] 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
|
||||
|
||||
[5] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[6] Austein, R. and S. Weiler, "Clarifications and Implementation
|
||||
Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
|
||||
(work in progress), January 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 13]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
David Blacka
|
||||
VeriSign, Inc.
|
||||
21355 Ridgetop Circle
|
||||
Dulles, VA 20166
|
||||
US
|
||||
|
||||
Phone: +1 703 948 3200
|
||||
Email: davidb@verisign.com
|
||||
URI: http://www.verisignlabs.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 14]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 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.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 15]
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
|
||||
This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted
|
||||
from the Internet-Drafts directory. An Internet-Draft expires 185 days from
|
||||
the date that it is posted unless it is replaced by an updated version, or the
|
||||
Secretariat has been notified that the document is under official review by the
|
||||
IESG or has been passed to the RFC Editor for review and/or publication as an
|
||||
RFC. This Internet-Draft was not published as an RFC.
|
||||
|
||||
Internet-Drafts are not archival documents, and copies of Internet-Drafts that have
|
||||
been deleted from the directory are not available. The Secretariat does not have
|
||||
any information regarding the future plans of the author(s) or working group, if
|
||||
applicable, with respect to this deleted Internet-Draft. For more information, or
|
||||
to request a copy of the document, please contact the author(s) directly.
|
||||
|
||||
Draft Author(s):
|
||||
Remco van Mook <remco@virtu.nl>,
|
||||
Bert Hubert <bert.hubert@netherlabs.nl>
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,464 +0,0 @@
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
Expires: September 2006 March 2006
|
||||
|
||||
|
||||
DSA Keying and Signature Information in the DNS
|
||||
--- ------ --- --------- ----------- -- --- ---
|
||||
<draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
|
||||
Donald E. Eastlake 3rd
|
||||
|
||||
|
||||
Status of This Document
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Distribution of this document is unlimited. Comments should be sent
|
||||
to the DNS extensions working group mailing list
|
||||
<namedroppers@ops.ietf.org>.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/1id-abstracts.html
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html
|
||||
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
The standard method of encoding US Government Digital Signature
|
||||
Algorithm keying and signature information for use in the Domain Name
|
||||
System is specified.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 1]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
Status of This Document....................................1
|
||||
Abstract...................................................1
|
||||
|
||||
Table of Contents..........................................2
|
||||
|
||||
1. Introduction............................................3
|
||||
2. DSA Keying Information..................................3
|
||||
3. DSA Signature Information...............................4
|
||||
4. Performance Considerations..............................4
|
||||
5. Security Considerations.................................5
|
||||
6. IANA Considerations.....................................5
|
||||
Copyright, Disclaimer, and Additional IPR Provisions.......5
|
||||
|
||||
Normative References.......................................7
|
||||
Informative References.....................................7
|
||||
|
||||
Author's Address...........................................8
|
||||
Expiration and File Name...................................8
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 2]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) is the global hierarchical replicated
|
||||
distributed database system for Internet addressing, mail proxy, and
|
||||
other information [RFC 1034, 1035]. The DNS has been extended to
|
||||
include digital signatures and cryptographic keys as described in
|
||||
[RFC 4033, 4034, 4035] and additional work is underway which would
|
||||
require the storage of keying and signature information in the DNS.
|
||||
|
||||
This document describes how to encode US Government Digital Signature
|
||||
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
|
||||
US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
|
||||
|
||||
|
||||
|
||||
2. DSA Keying Information
|
||||
|
||||
When DSA public keys are stored in the DNS, the structure of the
|
||||
relevant part of the RDATA part of the RR being used is the fields
|
||||
listed below in the order given.
|
||||
|
||||
The period of key validity is not included in this data but is
|
||||
indicated separately, for example by an RR such as RRSIG which signs
|
||||
and authenticates the RR containing the keying information.
|
||||
|
||||
Field Size
|
||||
----- ----
|
||||
T 1 octet
|
||||
Q 20 octets
|
||||
P 64 + T*8 octets
|
||||
G 64 + T*8 octets
|
||||
Y 64 + T*8 octets
|
||||
|
||||
As described in [FIPS 186-2] and [Schneier], T is a key size
|
||||
parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
|
||||
is greater than 8 is reserved and the remainder of the data may have
|
||||
a different format in that case.) Q is a prime number selected at
|
||||
key generation time such that 2**159 < Q < 2**160. Thus Q is always
|
||||
20 octets long and, as with all other fields, is stored in "big-
|
||||
endian" network order. P, G, and Y are calculated as directed by the
|
||||
[FIPS 186-2] key generation algorithm [Schneier]. P is in the range
|
||||
2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
|
||||
and Y are quantities modulo P and so can be up to the same length as
|
||||
P and are allocated fixed size fields with the same number of octets
|
||||
as P.
|
||||
|
||||
During the key generation process, a random number X must be
|
||||
generated such that 1 <= X <= Q-1. X is the private key and is used
|
||||
in the final step of public key generation where Y is computed as
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 3]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Y = G**X mod P
|
||||
|
||||
|
||||
|
||||
3. DSA Signature Information
|
||||
|
||||
The portion of the RDATA area used for US Digital Signature Algorithm
|
||||
signature information is shown below with fields in the order they
|
||||
are listed and the contents of each multi-octet field in "big-endian"
|
||||
network order.
|
||||
|
||||
Field Size
|
||||
----- ----
|
||||
T 1 octet
|
||||
R 20 octets
|
||||
S 20 octets
|
||||
|
||||
First, the data signed must be determined. Then the following steps
|
||||
are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
|
||||
specified in the public key [Schneier]:
|
||||
|
||||
hash = SHA-1 ( data )
|
||||
|
||||
Generate a random K such that 0 < K < Q.
|
||||
|
||||
R = ( G**K mod P ) mod Q
|
||||
|
||||
S = ( K**(-1) * (hash + X*R) ) mod Q
|
||||
|
||||
For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
|
||||
3174].
|
||||
|
||||
Since Q is 160 bits long, R and S can not be larger than 20 octets,
|
||||
which is the space allocated.
|
||||
|
||||
T is copied from the public key. It is not logically necessary in
|
||||
the SIG but is present so that values of T > 8 can more conveniently
|
||||
be used as an escape for extended versions of DSA or other algorithms
|
||||
as later standardized.
|
||||
|
||||
|
||||
|
||||
4. Performance Considerations
|
||||
|
||||
General signature generation speeds are roughly the same for RSA [RFC
|
||||
3110] and DSA. With sufficient pre-computation, signature generation
|
||||
with DSA is faster than RSA. Key generation is also faster for DSA.
|
||||
However, signature verification is an order of magnitude slower than
|
||||
RSA when the RSA public exponent is chosen to be small, as is
|
||||
recommended for some applications.
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 4]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Current DNS implementations are optimized for small transfers,
|
||||
typically less than 512 bytes including DNS overhead. Larger
|
||||
transfers will perform correctly and extensions have been
|
||||
standardized [RFC 2671] to make larger transfers more efficient, it
|
||||
is still advisable at this time to make reasonable efforts to
|
||||
minimize the size of RR sets containing keying and/or signature
|
||||
inforamtion consistent with adequate security.
|
||||
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Keys retrieved from the DNS should not be trusted unless (1) they
|
||||
have been securely obtained from a secure resolver or independently
|
||||
verified by the user and (2) this secure resolver and secure
|
||||
obtainment or independent verification conform to security policies
|
||||
acceptable to the user. As with all cryptographic algorithms,
|
||||
evaluating the necessary strength of the key is essential and
|
||||
dependent on local policy.
|
||||
|
||||
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
|
||||
current DSA standard may limit the security of DSA. For particular
|
||||
applications, implementors are encouraged to consider the range of
|
||||
available algorithms and key sizes.
|
||||
|
||||
DSA assumes the ability to frequently generate high quality random
|
||||
numbers. See [random] for guidance. DSA is designed so that if
|
||||
biased rather than random numbers are used, high bandwidth covert
|
||||
channels are possible. See [Schneier] and more recent research. The
|
||||
leakage of an entire DSA private key in only two DSA signatures has
|
||||
been demonstrated. DSA provides security only if trusted
|
||||
implementations, including trusted random number generation, are
|
||||
used.
|
||||
|
||||
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
Allocation of meaning to values of the T parameter that are not
|
||||
defined herein (i.e., > 8 ) requires an IETF standards actions. It
|
||||
is intended that values unallocated herein be used to cover future
|
||||
extensions of the DSS standard.
|
||||
|
||||
|
||||
|
||||
Copyright, Disclaimer, and Additional IPR Provisions
|
||||
|
||||
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.
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 5]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 6]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Normative References
|
||||
|
||||
[FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
|
||||
Signature Standard, 27 January 2000.
|
||||
|
||||
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
|
||||
|
||||
Informative References
|
||||
|
||||
[RFC 1034] - "Domain names - concepts and facilities", P.
|
||||
Mockapetris, 11/01/1987.
|
||||
|
||||
[RFC 1035] - "Domain names - implementation and specification", P.
|
||||
Mockapetris, 11/01/1987.
|
||||
|
||||
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
|
||||
1999.
|
||||
|
||||
[RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
|
||||
(DNS)", D. Eastlake 3rd. May 2001.
|
||||
|
||||
[RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
|
||||
Jones, September 2001.
|
||||
|
||||
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
|
||||
"Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
|
||||
|
||||
[Schneier] - "Applied Cryptography Second Edition: protocols,
|
||||
algorithms, and source code in C" (second edition), Bruce Schneier,
|
||||
1996, John Wiley and Sons, ISBN 0-471-11709-9.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 7]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Donald E. Eastlake 3rd
|
||||
Motorola Labortories
|
||||
155 Beaver Street
|
||||
Milford, MA 01757 USA
|
||||
|
||||
Telephone: +1-508-786-7554(w)
|
||||
EMail: Donald.Eastlake@motorola.com
|
||||
|
||||
|
||||
|
||||
Expiration and File Name
|
||||
|
||||
This draft expires in September 2006.
|
||||
|
||||
Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 8]
|
||||
|
||||
@@ -1,580 +0,0 @@
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
Expires: September 2006 March 2006
|
||||
|
||||
|
||||
|
||||
|
||||
Storage of Diffie-Hellman Keying Information in the DNS
|
||||
------- -- -------------- ------ ----------- -- --- ---
|
||||
<draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
|
||||
|
||||
|
||||
|
||||
Status of This Document
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of BCP 79.
|
||||
|
||||
Distribution of this document is unlimited. Comments should be sent
|
||||
to the DNS extensions working group mailing list
|
||||
<namedroppers@ops.ietf.org>.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/1id-abstracts.html
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
The standard method for encoding Diffie-Hellman keys in the Domain
|
||||
Name System is specified.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 1]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Acknowledgements
|
||||
|
||||
Part of the format for Diffie-Hellman keys and the description
|
||||
thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
|
||||
and Hemma Prafullchandra. In addition, the following persons
|
||||
provided useful comments that were incorporated into the predecessor
|
||||
of this document: Ran Atkinson, Thomas Narten.
|
||||
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
Status of This Document....................................1
|
||||
Abstract...................................................1
|
||||
|
||||
Acknowledgements...........................................2
|
||||
Table of Contents..........................................2
|
||||
|
||||
1. Introduction............................................3
|
||||
1.1 About This Document....................................3
|
||||
1.2 About Diffie-Hellman...................................3
|
||||
2. Encoding Diffie-Hellman Keying Information..............4
|
||||
3. Performance Considerations..............................5
|
||||
4. IANA Considerations.....................................5
|
||||
5. Security Considerations.................................5
|
||||
Copyright, Disclaimer, and Additional IPR Provisions.......5
|
||||
|
||||
Normative References.......................................7
|
||||
Informative Refences.......................................7
|
||||
|
||||
Author's Address...........................................8
|
||||
Expiration and File Name...................................8
|
||||
|
||||
Appendix A: Well known prime/generator pairs...............9
|
||||
A.1. Well-Known Group 1: A 768 bit prime..................9
|
||||
A.2. Well-Known Group 2: A 1024 bit prime.................9
|
||||
A.3. Well-Known Group 3: A 1536 bit prime................10
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 2]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) is the global hierarchical replicated
|
||||
distributed database system for Internet addressing, mail proxy, and
|
||||
similar information [RFC 1034, 1035]. The DNS has been extended to
|
||||
include digital signatures and cryptographic keys as described in
|
||||
[RFC 4033, 4034, 4035] and additonal work is underway which would use
|
||||
the storage of keying information in the DNS.
|
||||
|
||||
|
||||
|
||||
1.1 About This Document
|
||||
|
||||
This document describes how to store Diffie-Hellman keys in the DNS.
|
||||
Familiarity with the Diffie-Hellman key exchange algorithm is assumed
|
||||
[Schneier, RFC 2631].
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in RFC 2119.
|
||||
|
||||
|
||||
|
||||
1.2 About Diffie-Hellman
|
||||
|
||||
Diffie-Hellman requires two parties to interact to derive keying
|
||||
information which can then be used for authentication. Thus Diffie-
|
||||
Hellman is inherently a key agreement algorithm. As a result, no
|
||||
format is defined for Diffie-Hellman "signature information". For
|
||||
example, assume that two parties have local secrets "i" and "j".
|
||||
Assume they each respectively calculate X and Y as follows:
|
||||
|
||||
X = g**i ( mod p )
|
||||
|
||||
Y = g**j ( mod p )
|
||||
|
||||
They exchange these quantities and then each calculates a Z as
|
||||
follows:
|
||||
|
||||
Zi = Y**i ( mod p )
|
||||
|
||||
Zj = X**j ( mod p )
|
||||
|
||||
Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
|
||||
secret between the two parties that an adversary who does not know i
|
||||
or j will not be able to learn from the exchanged messages (unless
|
||||
the adversary can derive i or j by performing a discrete logarithm
|
||||
mod p which is hard for strong p and g).
|
||||
|
||||
The private key for each party is their secret i (or j). The public
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 3]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
key is the pair p and g, which is the same for both parties, and
|
||||
their individual X (or Y).
|
||||
|
||||
For further information about Diffie-Hellman and precautions to take
|
||||
in deciding on a p and g, see [RFC 2631].
|
||||
|
||||
|
||||
|
||||
2. Encoding Diffie-Hellman Keying Information
|
||||
|
||||
When Diffie-Hellman keys appear within the RDATA portion of a RR,
|
||||
they are encoded as shown below.
|
||||
|
||||
The period of key validity is not included in this data but is
|
||||
indicated separately, for example by an RR such as RRSIG which signs
|
||||
and authenticates the RR containing the keying information.
|
||||
|
||||
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 flags | protocol | algorithm=2 |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| prime length (or flag) | prime (p) (or special) /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
/ prime (p) (variable length) | generator length |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| generator (g) (variable length) |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| public value length | public value (variable length)/
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
/ public value (g^i mod p) (variable length) |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
Prime length is the length of the Diffie-Hellman prime (p) in bytes
|
||||
if it is 16 or greater. Prime contains the binary representation of
|
||||
the Diffie-Hellman prime with most significant byte first (i.e., in
|
||||
network order). If "prime length" field is 1 or 2, then the "prime"
|
||||
field is actually an unsigned index into a table of 65,536
|
||||
prime/generator pairs and the generator length SHOULD be zero. See
|
||||
Appedix A for defined table entries and Section 4 for information on
|
||||
allocating additional table entries. The meaning of a zero or 3
|
||||
through 15 value for "prime length" is reserved.
|
||||
|
||||
Generator length is the length of the generator (g) in bytes.
|
||||
Generator is the binary representation of generator with most
|
||||
significant byte first. PublicValueLen is the Length of the Public
|
||||
Value (g**i (mod p)) in bytes. PublicValue is the binary
|
||||
representation of the DH public value with most significant byte
|
||||
first.
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 4]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
3. Performance Considerations
|
||||
|
||||
Current DNS implementations are optimized for small transfers,
|
||||
typically less than 512 bytes including DNS overhead. Larger
|
||||
transfers will perform correctly and extensions have been
|
||||
standardized [RFC 2671] to make larger transfers more efficient. But
|
||||
it is still advisable at this time to make reasonable efforts to
|
||||
minimize the size of RR sets containing keying information consistent
|
||||
with adequate security.
|
||||
|
||||
|
||||
|
||||
4. IANA Considerations
|
||||
|
||||
Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
|
||||
an IETF consensus as defined in [RFC 2434].
|
||||
|
||||
Well known prime/generator pairs number 0x0000 through 0x07FF can
|
||||
only be assigned by an IETF standards action. [RFC 2539], the
|
||||
Proposed Standard predecessor of this document, assigned 0x0001
|
||||
through 0x0002. This document additionally assigns 0x0003. Pairs
|
||||
number 0s0800 through 0xBFFF can be assigned based on RFC
|
||||
documentation. Pairs number 0xC000 through 0xFFFF are available for
|
||||
private use and are not centrally coordinated. Use of such private
|
||||
pairs outside of a closed environment may result in conflicts and/or
|
||||
security failures.
|
||||
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Keying information retrieved from the DNS should not be trusted
|
||||
unless (1) it has been securely obtained from a secure resolver or
|
||||
independently verified by the user and (2) this secure resolver and
|
||||
secure obtainment or independent verification conform to security
|
||||
policies acceptable to the user. As with all cryptographic
|
||||
algorithms, evaluating the necessary strength of the key is important
|
||||
and dependent on security policy.
|
||||
|
||||
In addition, the usual Diffie-Hellman key strength considerations
|
||||
apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
|
||||
SHOULD be "large", etc. See [RFC 2631, Schneier].
|
||||
|
||||
|
||||
|
||||
Copyright, Disclaimer, and Additional IPR Provisions
|
||||
|
||||
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.
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 5]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 6]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Normative References
|
||||
|
||||
[RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
|
||||
in RFCs", T. Narten, H. Alvestrand, October 1998.
|
||||
|
||||
[RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
|
||||
1999.
|
||||
|
||||
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
|
||||
|
||||
Informative Refences
|
||||
|
||||
[RFC 1034] - "Domain names - concepts and facilities", P.
|
||||
Mockapetris, November 1987.
|
||||
|
||||
[RFC 1035] - "Domain names - implementation and specification", P.
|
||||
Mockapetris, November 1987.
|
||||
|
||||
[RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
|
||||
System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
|
||||
|
||||
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
|
||||
1999.
|
||||
|
||||
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
|
||||
Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
|
||||
and Sons.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 7]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
155 Beaver Street
|
||||
Milford, MA 01757 USA
|
||||
|
||||
Telephone: +1-508-786-7554
|
||||
EMail: Donald.Eastlake@motorola.com
|
||||
|
||||
|
||||
|
||||
Expiration and File Name
|
||||
|
||||
This draft expires in September 2006.
|
||||
|
||||
Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 8]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Appendix A: Well known prime/generator pairs
|
||||
|
||||
These numbers are copied from the IPSEC effort where the derivation
|
||||
of these values is more fully explained and additional information is
|
||||
available. Richard Schroeppel performed all the mathematical and
|
||||
computational work for this appendix.
|
||||
|
||||
|
||||
|
||||
A.1. Well-Known Group 1: A 768 bit prime
|
||||
|
||||
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
|
||||
decimal value is
|
||||
155251809230070893513091813125848175563133404943451431320235
|
||||
119490296623994910210725866945387659164244291000768028886422
|
||||
915080371891804634263272761303128298374438082089019628850917
|
||||
0691316593175367469551763119843371637221007210577919
|
||||
|
||||
Prime modulus: Length (32 bit words): 24, Data (hex):
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
|
||||
|
||||
Generator: Length (32 bit words): 1, Data (hex): 2
|
||||
|
||||
|
||||
|
||||
A.2. Well-Known Group 2: A 1024 bit prime
|
||||
|
||||
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
|
||||
Its decimal value is
|
||||
179769313486231590770839156793787453197860296048756011706444
|
||||
423684197180216158519368947833795864925541502180565485980503
|
||||
646440548199239100050792877003355816639229553136239076508735
|
||||
759914822574862575007425302077447712589550957937778424442426
|
||||
617334727629299387668709205606050270810842907692932019128194
|
||||
467627007
|
||||
|
||||
Prime modulus: Length (32 bit words): 32, Data (hex):
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
|
||||
FFFFFFFF FFFFFFFF
|
||||
|
||||
Generator: Length (32 bit words): 1, Data (hex): 2
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 9]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
A.3. Well-Known Group 3: A 1536 bit prime
|
||||
|
||||
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
|
||||
Its decimal value is
|
||||
241031242692103258855207602219756607485695054850245994265411
|
||||
694195810883168261222889009385826134161467322714147790401219
|
||||
650364895705058263194273070680500922306273474534107340669624
|
||||
601458936165977404102716924945320037872943417032584377865919
|
||||
814376319377685986952408894019557734611984354530154704374720
|
||||
774996976375008430892633929555996888245787241299381012913029
|
||||
459299994792636526405928464720973038494721168143446471443848
|
||||
8520940127459844288859336526896320919633919
|
||||
|
||||
Prime modulus Length (32 bit words): 48, Data (hex):
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
|
||||
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
|
||||
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
|
||||
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
|
||||
|
||||
Generator: Length (32 bit words): 1, Data (hex): 2
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 10]
|
||||
|
||||
@@ -1,480 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DNSEXT Working Group Paul Vixie, ISC
|
||||
INTERNET-DRAFT
|
||||
<draft-ietf-dnsext-rfc2671bis-edns0-01.txt> March 17, 2008
|
||||
|
||||
Intended Status: Standards Track
|
||||
Obsoletes: 2671 (if approved)
|
||||
|
||||
|
||||
Revised extension mechanisms for DNS (EDNS0)
|
||||
|
||||
|
||||
Status of this Memo
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of 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.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The IETF Trust (2007).
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
The Domain Name System's wire protocol includes a number of fixed
|
||||
fields whose range has been or soon will be exhausted and does not
|
||||
allow clients to advertise their capabilities to servers. This
|
||||
document describes backward compatible mechanisms for allowing the
|
||||
protocol to grow.
|
||||
|
||||
|
||||
|
||||
Expires September 2008 [Page 1]
|
||||
|
||||
INTERNET-DRAFT EDNS0 March 2008
|
||||
|
||||
|
||||
1 - Introduction
|
||||
|
||||
1.1. DNS (see [RFC1035]) specifies a Message Format and within such
|
||||
messages there are standard formats for encoding options, errors, and
|
||||
name compression. The maximum allowable size of a DNS Message is fixed.
|
||||
Many of DNS's protocol limits are too small for uses which are or which
|
||||
are desired to become common. There is no way for implementations to
|
||||
advertise their capabilities.
|
||||
|
||||
1.2. Unextended agents will not know how to interpret the protocol
|
||||
extensions detailed here. In practice, these clients will be upgraded
|
||||
when they have need of a new feature, and only new features will make
|
||||
use of the extensions. Extended agents must be prepared for behaviour
|
||||
of unextended clients in the face of new protocol elements, and fall
|
||||
back gracefully to unextended DNS. RFC 2671 originally has proposed
|
||||
extensions to the basic DNS protocol to overcome these deficiencies.
|
||||
This memo refines that specification and obsoletes RFC 2671.
|
||||
|
||||
1.3. 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].
|
||||
|
||||
2 - Affected Protocol Elements
|
||||
|
||||
2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
|
||||
word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
|
||||
1-bit flags. The original reserved Z bits have been allocated to
|
||||
various purposes, and most of the RCODE values are now in use. More
|
||||
flags and more possible RCODEs are needed. The OPT pseudo-RR specified
|
||||
in Section 4 contains subfields that carry a bit field extension of the
|
||||
RCODE field and additional flag bits, respectively; for details see
|
||||
Section 4.6 below.
|
||||
|
||||
2.2. The first two bits of a wire format domain label are used to denote
|
||||
the type of the label. [RFC1035 4.1.4] allocates two of the four
|
||||
possible types and reserves the other two. Proposals for use of the
|
||||
remaining types far outnumber those available. More label types were
|
||||
needed, and an extension mechanism was proposed in RFC 2671 [RFC2671
|
||||
Section 3]. Section 3 of this document reserves DNS labels with a first
|
||||
octet in the range of 64-127 decimal (label type 01) for future
|
||||
standardization of Extended DNS Labels.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires September 2008 [Page 2]
|
||||
|
||||
INTERNET-DRAFT EDNS0 March 2008
|
||||
|
||||
|
||||
2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
|
||||
While the minimum maximum reassembly buffer size still allows a limit of
|
||||
512 octets of UDP payload, most of the hosts now connected to the
|
||||
Internet are able to reassemble larger datagrams. Some mechanism must
|
||||
be created to allow requestors to advertise larger buffer sizes to
|
||||
responders. To this end, the OPT pseudo-RR specified in Section 4
|
||||
contains a maximum payload size field; for details see Section 4.5
|
||||
below.
|
||||
|
||||
3 - Extended Label Types
|
||||
|
||||
The first octet in the on-the-wire representation of a DNS label
|
||||
specifies the label type; the basic DNS specification [RFC1035]
|
||||
dedicates the two most significant bits of that octet for this purpose.
|
||||
|
||||
This document reserves DNS label type 0b01 for use as an indication for
|
||||
Extended Label Types. A specific extended label type is selected by the
|
||||
6 least significant bits of the first octet. Thus, Extended Label Types
|
||||
are indicated by the values 64-127 (0b01xxxxxx) in the first octet of
|
||||
the label.
|
||||
|
||||
Allocations from this range are to be made for IETF documents fully
|
||||
describing the syntax and semantics as well as the applicability of the
|
||||
particular Extended Label Type.
|
||||
|
||||
This document does not describe any specific Extended Label Type.
|
||||
|
||||
4 - OPT pseudo-RR
|
||||
|
||||
4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data
|
||||
section of a request, and to responses to such requests. An OPT is
|
||||
called a pseudo-RR because it pertains to a particular transport level
|
||||
message and not to any actual DNS data. OPT RRs MUST NOT be cached,
|
||||
forwarded, or stored in or loaded from master files. The quantity of
|
||||
OPT pseudo-RRs per message MUST be either zero or one, but not greater.
|
||||
|
||||
4.2. An OPT RR has a fixed part and a variable set of options expressed
|
||||
as {attribute, value} pairs. The fixed part holds some DNS meta data
|
||||
and also a small collection of new protocol elements which we expect to
|
||||
be so popular that it would be a waste of wire space to encode them as
|
||||
{attribute, value} pairs.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires September 2008 [Page 3]
|
||||
|
||||
INTERNET-DRAFT EDNS0 March 2008
|
||||
|
||||
|
||||
4.3. The fixed part of an OPT RR is structured as follows:
|
||||
|
||||
Field Name Field Type Description
|
||||
------------------------------------------------------
|
||||
NAME domain name empty (root domain)
|
||||
TYPE u_int16_t OPT (41)
|
||||
CLASS u_int16_t sender's UDP payload size
|
||||
TTL u_int32_t extended RCODE and flags
|
||||
RDLEN u_int16_t describes RDATA
|
||||
RDATA octet stream {attribute,value} pairs
|
||||
|
||||
|
||||
4.4. The variable part of an OPT RR is encoded in its RDATA and is
|
||||
structured as zero or more of the following:
|
||||
|
||||
: +0 (MSB) : +1 (LSB) :
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
0: | OPTION-CODE |
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
2: | OPTION-LENGTH |
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
4: | |
|
||||
/ OPTION-DATA /
|
||||
/ /
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
|
||||
|
||||
OPTION-CODE (Assigned by IANA.)
|
||||
|
||||
OPTION-LENGTH Size (in octets) of OPTION-DATA.
|
||||
|
||||
OPTION-DATA Varies per OPTION-CODE.
|
||||
|
||||
4.4.1. Order of appearance of option tuples is never relevant. Any
|
||||
option whose meaning is affected by other options is so affected no
|
||||
matter which one comes first in the OPT RDATA.
|
||||
|
||||
4.4.2. Any OPTION-CODE values not understood by a responder or requestor
|
||||
MUST be ignored. So, specifications of such options might wish to
|
||||
include some kind of signalled acknowledgement. For example, an option
|
||||
specification might say that if a responder sees option XYZ, it SHOULD
|
||||
include option XYZ in its response.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires September 2008 [Page 4]
|
||||
|
||||
INTERNET-DRAFT EDNS0 March 2008
|
||||
|
||||
|
||||
4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
|
||||
field) is the number of octets of the largest UDP payload that can be
|
||||
reassembled and delivered in the sender's network stack. Note that path
|
||||
MTU, with or without fragmentation, may be smaller than this. Values
|
||||
lower than 512 are undefined, and may be treated as format errors, or
|
||||
may be treated as equal to 512, at the implementor's discretion.
|
||||
|
||||
4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
|
||||
reassembly buffer. Choosing 1280 on an Ethernet connected requestor
|
||||
would be reasonable. The consequence of choosing too large a value may
|
||||
be an ICMP message from an intermediate gateway, or even a silent drop
|
||||
of the response message.
|
||||
|
||||
4.5.2. Both requestors and responders are advised to take account of the
|
||||
path's discovered MTU (if already known) when considering message sizes.
|
||||
|
||||
4.5.3. The requestor's maximum payload size can change over time, and
|
||||
therefore MUST NOT be cached for use beyond the transaction in which it
|
||||
is advertised.
|
||||
|
||||
4.5.4. The responder's maximum payload size can change over time, but
|
||||
can be reasonably expected to remain constant between two sequential
|
||||
transactions; for example, a meaningless QUERY to discover a responder's
|
||||
maximum UDP payload size, followed immediately by an UPDATE which takes
|
||||
advantage of this size. (This is considered preferrable to the outright
|
||||
use of TCP for oversized requests, if there is any reason to suspect
|
||||
that the responder implements EDNS, and if a request will not fit in the
|
||||
default 512 payload size limit.)
|
||||
|
||||
4.5.5. Due to transaction overhead, it is unwise to advertise an
|
||||
architectural limit as a maximum UDP payload size. Just because your
|
||||
stack can reassemble 64KB datagrams, don't assume that you want to spend
|
||||
more than about 4KB of state memory per ongoing transaction.
|
||||
|
||||
4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
|
||||
are structured as follows:
|
||||
|
||||
: +0 (MSB) : +1 (LSB) :
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
0: | EXTENDED-RCODE | VERSION |
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
2: | DO| Z |
|
||||
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires September 2008 [Page 5]
|
||||
|
||||
INTERNET-DRAFT EDNS0 March 2008
|
||||
|
||||
|
||||
EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that
|
||||
EXTENDED-RCODE value zero (0) indicates that an
|
||||
unextended RCODE is in use (values zero (0) through
|
||||
fifteen (15)).
|
||||
|
||||
VERSION Indicates the implementation level of whoever sets it.
|
||||
Full conformance with this specification is indicated by
|
||||
version zero (0). Requestors are encouraged to set this
|
||||
to the lowest implemented level capable of expressing a
|
||||
transaction, to minimize the responder and network load
|
||||
of discovering the greatest common implementation level
|
||||
between requestor and responder. A requestor's version
|
||||
numbering strategy should ideally be a run time
|
||||
configuration option.
|
||||
|
||||
If a responder does not implement the VERSION level of
|
||||
the request, then it answers with RCODE=BADVERS. All
|
||||
responses MUST be limited in format to the VERSION level
|
||||
of the request, but the VERSION of each response MUST be
|
||||
the highest implementation level of the responder. In
|
||||
this way a requestor will learn the implementation level
|
||||
of a responder as a side effect of every response,
|
||||
including error responses, including RCODE=BADVERS.
|
||||
|
||||
DO DNSSEC OK bit [RFC3225].
|
||||
|
||||
Z Set to zero by senders and ignored by receivers, unless
|
||||
modified in a subsequent specification [IANAFLAGS].
|
||||
|
||||
5 - Transport Considerations
|
||||
|
||||
5.1. The presence of an OPT pseudo-RR in a request is an indication that
|
||||
the requestor fully implements the given version of EDNS, and can
|
||||
correctly understand any response that conforms to that feature's
|
||||
specification.
|
||||
|
||||
5.2. Lack of use of these features in a request is an indication that
|
||||
the requestor does not implement any part of this specification and that
|
||||
the responder SHOULD NOT use any protocol extension described here in
|
||||
its response.
|
||||
|
||||
5.3. Responders who do not understand these protocol extensions are
|
||||
expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or
|
||||
to appear to "time out" due to inappropriate action by a "middle box"
|
||||
such as a NAT, or to ignore extensions and respond only to unextended
|
||||
|
||||
|
||||
|
||||
Expires September 2008 [Page 6]
|
||||
|
||||
INTERNET-DRAFT EDNS0 March 2008
|
||||
|
||||
|
||||
protocol elements. Therefore use of extensions SHOULD be "probed" such
|
||||
that a responder who isn't known to support them be allowed a retry with
|
||||
no extensions if it responds with such an RCODE, or does not respond.
|
||||
If a responder's capability level is cached by a requestor, a new probe
|
||||
SHOULD be sent periodically to test for changes to responder capability.
|
||||
|
||||
5.4. If EDNS is used in a request, and the response arrives with TC set
|
||||
and with no EDNS OPT RR, a requestor should assume that truncation
|
||||
prevented the OPT RR from being appended by the responder, and further,
|
||||
that EDNS is not used in the response. Correspondingly, an EDNS
|
||||
responder who cannot fit all necessary elements (including an OPT RR)
|
||||
into a response, should respond with a normal (unextended) DNS response,
|
||||
possibly setting TC if the response will not fit in the unextended
|
||||
response message's 512-octet size.
|
||||
|
||||
6 - Security Considerations
|
||||
|
||||
Requestor-side specification of the maximum buffer size may open a new
|
||||
DNS denial of service attack if responders can be made to send messages
|
||||
which are too large for intermediate gateways to forward, thus leading
|
||||
to potential ICMP storms between gateways and responders.
|
||||
|
||||
7 - IANA Considerations
|
||||
|
||||
IANA has allocated RR type code 41 for OPT.
|
||||
|
||||
This document controls the following IANA sub-registries in registry
|
||||
"DOMAIN NAME SYSTEM PARAMETERS":
|
||||
|
||||
"EDNS Extended Label Type"
|
||||
"EDNS Option Codes"
|
||||
"EDNS Version Numbers"
|
||||
"Domain System Response Code"
|
||||
|
||||
IANA is advised to re-parent these subregistries to this document.
|
||||
|
||||
This document assigns label type 0b01xxxxxx as "EDNS Extended Label
|
||||
Type." We request that IANA record this assignment.
|
||||
|
||||
This document assigns option code 65535 to "Reserved for future
|
||||
expansion."
|
||||
|
||||
This document assigns EDNS Extended RCODE "16" to "BADVERS".
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires September 2008 [Page 7]
|
||||
|
||||
INTERNET-DRAFT EDNS0 March 2008
|
||||
|
||||
|
||||
IESG approval is required to create new entries in the EDNS Extended
|
||||
Label Type or EDNS Version Number registries, while any published RFC
|
||||
(including Informational, Experimental, or BCP) is grounds for
|
||||
allocation of an EDNS Option Code.
|
||||
|
||||
8 - Acknowledgements
|
||||
|
||||
Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
|
||||
Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten,
|
||||
Alfred Hoenes and Markku Savela were each instrumental in creating and
|
||||
refining this specification.
|
||||
|
||||
9 - References
|
||||
|
||||
[RFC1035] P. Mockapetris, "Domain Names - Implementation and
|
||||
Specification," RFC 1035, USC/Information Sciences
|
||||
Institute, November 1987.
|
||||
|
||||
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
|
||||
Requirement Levels," RFC 2119, Harvard University, March
|
||||
1997.
|
||||
|
||||
[RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671,
|
||||
Internet Software Consortium, August 1999.
|
||||
|
||||
[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC
|
||||
3225, Nominum Inc., December 2001.
|
||||
|
||||
[IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site
|
||||
http://www.iana.org/assignments/dns-header-flags, as of
|
||||
June 2005 or later.
|
||||
|
||||
10 - Author's Address
|
||||
|
||||
Paul Vixie
|
||||
Internet Systems Consortium
|
||||
950 Charter Street
|
||||
Redwood City, CA 94063
|
||||
+1 650 423 1301
|
||||
EMail: vixie@isc.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires September 2008 [Page 8]
|
||||
|
||||
INTERNET-DRAFT EDNS0 March 2008
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) 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 provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
Expires September 2008 [Page 9]
|
||||
|
||||
@@ -1,395 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
INTERNET-DRAFT A. Gustafsson
|
||||
Araneus Information Systems Oy
|
||||
September 23, 2009
|
||||
|
||||
Intended status: Draft Standard
|
||||
Obsoletes: RFC3597
|
||||
|
||||
Handling of Unknown DNS Resource Record (RR) Types
|
||||
draft-ietf-dnsext-rfc3597-bis-00.txt
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This Internet-Draft is submitted to IETF in full conformance with the
|
||||
provisions of BCP 78 and BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that other
|
||||
groups may also distribute working documents as Internet-Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/1id-abstracts.html
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2009 IETF Trust and the persons identified as the
|
||||
document authors. All rights reserved.
|
||||
|
||||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||||
Provisions Relating to IETF Documents in effect on the date of
|
||||
publication of this document (http://trustee.ietf.org/license-info).
|
||||
Please review these documents carefully, as they describe your rights
|
||||
and restrictions with respect to this document.
|
||||
|
||||
Abstract
|
||||
|
||||
Extending the Domain Name System (DNS) with new Resource Record (RR)
|
||||
types should not requires changes to name server software. This
|
||||
document specifies how new RR types are transparently handled by DNS
|
||||
software.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires March 2010 Standards Track [Page 1]
|
||||
|
||||
draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The DNS [RFC1034] is designed to be extensible to support new
|
||||
services through the introduction of new resource record (RR) types.
|
||||
Nevertheless, DNS implementations have historically required software
|
||||
changes to support new RR types, not only at the authoritative DNS
|
||||
server providing the new information and the client making use of it,
|
||||
but also at all slave servers for the zone containing it, and in some
|
||||
cases also at caching name servers and forwarders used by the client.
|
||||
Because the deployment of new DNS software is slow and expensive,
|
||||
this has been a significant impediment to supporting new services in
|
||||
the DNS.
|
||||
|
||||
[RFC3597] defined DNS implementation behavior and procedures for
|
||||
defining new RR types aimed at simplifying the deployment of new RR
|
||||
types by allowing them to be treated transparently by existing
|
||||
implementations. Thanks to the widespread adoption of that
|
||||
specification, much of the DNS is now capable of handling new record
|
||||
types without software changes.
|
||||
|
||||
This document is a self-contained revised specification supplanting
|
||||
and obsoleting [RFC3597].
|
||||
|
||||
2. Definitions
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
An "RR of unknown type" is an RR whose RDATA format is not known to
|
||||
the DNS implementation at hand, and whose type is not an assigned
|
||||
QTYPE or Meta-TYPE as specified in [RFC5395] (section 3.1) nor within
|
||||
the range reserved in that section for assignment only to QTYPEs and
|
||||
Meta-TYPEs. Such an RR cannot be converted to a type-specific text
|
||||
format, compressed, or otherwise handled in a type-specific way.
|
||||
|
||||
In the case of a type whose RDATA format is class specific, an RR is
|
||||
considered to be of unknown type when the RDATA format for that
|
||||
combination of type and class is not known.
|
||||
|
||||
3. Transparency
|
||||
|
||||
To enable new RR types to be deployed without server changes, name
|
||||
servers and resolvers MUST handle RRs of unknown type transparently.
|
||||
That is, they must treat the RDATA section of such RRs as
|
||||
unstructured binary data, storing and transmitting it without change
|
||||
[RFC1123].
|
||||
|
||||
|
||||
|
||||
|
||||
Expires March 2010 Standards Track [Page 2]
|
||||
|
||||
draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
|
||||
|
||||
|
||||
To ensure the correct operation of equality comparison (section 6)
|
||||
and of the DNSSEC canonical form (section 7) when an RR type is known
|
||||
to some but not all of the servers involved, servers MUST also
|
||||
exactly preserve the RDATA of RRs of known type, except for changes
|
||||
due to compression or decompression where allowed by section 4 of
|
||||
this document. In particular, the character case of domain names
|
||||
that are not subject to compression MUST be preserved.
|
||||
|
||||
4. Domain Name Compression
|
||||
|
||||
RRs containing compression pointers in the RDATA part cannot be
|
||||
treated transparently, as the compression pointers are only
|
||||
meaningful within the context of a DNS message. Transparently
|
||||
copying the RDATA into a new DNS message would cause the compression
|
||||
pointers to point at the corresponding location in the new message,
|
||||
which now contains unrelated data. This would cause the compressed
|
||||
name to be corrupted.
|
||||
|
||||
To avoid such corruption, servers MUST NOT compress domain names
|
||||
embedded in the RDATA of types that are class-specific or not well-
|
||||
known. This requirement was stated in [RFC1123] without defining the
|
||||
term "well-known"; it is hereby specified that only the RR types
|
||||
defined in [RFC1035] are to be considered "well-known".
|
||||
|
||||
Receiving servers MUST decompress domain names in RRs of well-known
|
||||
type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
|
||||
NXT, NAPTR, and SRV to ensure interoperability with implementations
|
||||
predating [RFC3597].
|
||||
|
||||
Specifications for new RR types that contain domain names within
|
||||
their RDATA MUST NOT allow the use of name compression for those
|
||||
names, and SHOULD explicitly state that the embedded domain names
|
||||
MUST NOT be compressed.
|
||||
|
||||
As noted in [RFC1123], the owner name of an RR is always eligible for
|
||||
compression.
|
||||
|
||||
5. Text Representation
|
||||
|
||||
In the "type" field of a master file line, an unknown RR type is
|
||||
represented by the word "TYPE" immediately followed by the decimal RR
|
||||
type number, with no intervening whitespace. In the "class" field,
|
||||
an unknown class is similarly represented as the word "CLASS"
|
||||
immediately followed by the decimal class number.
|
||||
|
||||
This convention allows types and classes to be distinguished from
|
||||
each other and from TTL values, allowing the "[<TTL>] [<class>]
|
||||
<type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
|
||||
|
||||
|
||||
|
||||
Expires March 2010 Standards Track [Page 3]
|
||||
|
||||
draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
|
||||
|
||||
|
||||
[RFC1035] to both be unambiguously parsed.
|
||||
|
||||
The RDATA section of an RR of unknown type is represented as a
|
||||
sequence of white space separated words as follows:
|
||||
|
||||
The special token \# (a backslash immediately followed by a hash
|
||||
sign), which identifies the RDATA as having the generic encoding
|
||||
defined herein rather than a traditional type-specific encoding.
|
||||
|
||||
An unsigned decimal integer specifying the RDATA length in octets.
|
||||
|
||||
Zero or more words of hexadecimal data encoding the actual RDATA
|
||||
field, each containing an even number of hexadecimal digits.
|
||||
|
||||
If the RDATA is of zero length, the text representation contains only
|
||||
the \# token and the single zero representing the length.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires March 2010 Standards Track [Page 4]
|
||||
|
||||
draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
|
||||
|
||||
|
||||
An implementation MAY also choose to represent some RRs of known type
|
||||
using the above generic representations for the type, class and/or
|
||||
RDATA, which carries the benefit of making the resulting master file
|
||||
portable to servers where these types are unknown. Using the generic
|
||||
representation for the RDATA of an RR of known type can also be
|
||||
useful in the case of an RR type where the text format varies
|
||||
depending on a version, protocol, or similar field (or several)
|
||||
embedded in the RDATA when such a field has a value for which no text
|
||||
format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
|
||||
0.
|
||||
|
||||
Even though an RR of known type represented in the \# format is
|
||||
effectively treated as an unknown type for the purpose of parsing the
|
||||
RDATA text representation, all further processing by the server MUST
|
||||
treat it as a known type and take into account any applicable type-
|
||||
specific rules regarding compression, canonicalization, etc.
|
||||
|
||||
The following are examples of RRs represented in this manner,
|
||||
illustrating various combinations of generic and type-specific
|
||||
encodings for the different fields of the master file format:
|
||||
|
||||
a.example. CLASS32 TYPE731 \# 6 abcd (
|
||||
ef 01 23 45 )
|
||||
b.example. HS TYPE62347 \# 0
|
||||
e.example. IN A \# 4 C0000201
|
||||
e.example. CLASS1 TYPE1 192.0.2.1
|
||||
|
||||
6. Equality Comparison
|
||||
|
||||
Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
|
||||
to be compared for equality. Two RRs of the same unknown type are
|
||||
considered equal when their RDATA is bitwise equal. To ensure that
|
||||
the outcome of the comparison is identical whether the RR is known to
|
||||
the server or not, specifications for new RR types MUST NOT specify
|
||||
type-specific comparison rules.
|
||||
|
||||
This implies that embedded domain names, being included in the
|
||||
overall bitwise comparison, are compared in a case-sensitive manner.
|
||||
|
||||
As a result, when a new RR type contains one or more embedded domain
|
||||
names, it is possible to have multiple RRs owned by the same name
|
||||
that differ only in the character case of the embedded domain
|
||||
name(s). This is similar to the existing possibility of multiple TXT
|
||||
records differing only in character case, and not expected to cause
|
||||
any problems in practice.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires March 2010 Standards Track [Page 5]
|
||||
|
||||
draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
|
||||
|
||||
|
||||
7. DNSSEC Considerations
|
||||
|
||||
The rules for the DNSSEC canonical form and ordering were updated to
|
||||
support transparent treatment of unknown types in [RFC3597]. Those
|
||||
updates have subsequently been integrated into the base DNSSEC
|
||||
specification, such that the DNSSEC canonical form and ordering are
|
||||
now specified in [RFC4034] or its successors rather than in this
|
||||
document.
|
||||
|
||||
8. Additional Section Processing
|
||||
|
||||
Unknown RR types cause no additional section processing. Future RR
|
||||
type specifications MAY specify type-specific additional section
|
||||
processing rules, but any such processing MUST be optional as it can
|
||||
only be performed by servers for which the RR type in case is known.
|
||||
|
||||
9. IANA Considerations
|
||||
|
||||
This document does not require any IANA actions.
|
||||
|
||||
10. Security Considerations
|
||||
|
||||
This specification is not believed to cause any new security
|
||||
problems, nor to solve any existing ones.
|
||||
|
||||
11. Normative References
|
||||
|
||||
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
|
||||
Facilities", STD 13, RFC 1034, November 1987.
|
||||
|
||||
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
|
||||
Specifications", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts --
|
||||
Application and Support", STD 3, RFC 1123, October 1989.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC5395] Eastlake, D., "Domain Name System (DNS) IANA
|
||||
Considerations", BCP 42, RFC 5395, November 2008.
|
||||
|
||||
12. Informative References
|
||||
|
||||
[RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
|
||||
Means for Expressing Location Information in the Domain
|
||||
Name System", RFC 1876, January 1996.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires March 2010 Standards Track [Page 6]
|
||||
|
||||
draft-ietf-dnsext-rfc3597-bis-00.txt July 2009
|
||||
|
||||
|
||||
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
|
||||
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
|
||||
RFC 2136, April 1997.
|
||||
|
||||
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
|
||||
(RR) Types", RFC 3597, September 2003.
|
||||
|
||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions",
|
||||
RFC 4034, March 2005.
|
||||
|
||||
14. Author's Address
|
||||
|
||||
Andreas Gustafsson
|
||||
Araneus Information Systems Oy
|
||||
PL 110
|
||||
02321 Espoo
|
||||
Finland
|
||||
|
||||
Phone: +358 40 547 2099
|
||||
EMail: gson@araneus.fi
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires March 2010 Standards Track [Page 7]
|
||||
|
||||
@@ -1,729 +0,0 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group M. StJohns
|
||||
Internet-Draft Nominum, Inc.
|
||||
Intended status: Informational November 29, 2006
|
||||
Expires: June 2, 2007
|
||||
|
||||
|
||||
Automated Updates of DNSSEC Trust Anchors
|
||||
draft-ietf-dnsext-trustupdate-timers-05
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of 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 June 2, 2007.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 1]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
(but not resolver resolution behavior), and the addition of a single
|
||||
flag bit to the DNSKEY record.
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
|
||||
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
|
||||
2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
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 . . . . . . . . . . . . . . . . . 11
|
||||
8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
|
||||
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
|
||||
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 13
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 2]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
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 space 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
|
||||
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 this 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].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 3]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
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 valid set of trust anchors for that trust point.
|
||||
|
||||
There are some issues with this approach which 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.
|
||||
|
||||
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 which didn't
|
||||
contain A. To fix this, we add a mechanism which 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 purposes except validating 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 which 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, 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.
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 4]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
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 which were
|
||||
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 which 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
|
||||
explictly 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 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 which has been configured for 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 or half the original TTL for the DNSKEY
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 5]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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 or 10% of the original TTL or 10% of the original
|
||||
expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
|
||||
origTTL, .1 * expireInterval)).
|
||||
|
||||
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 which contained
|
||||
the new key, whichever is greater. This ensures that at least two
|
||||
validated DNSKEY RRSets which 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 n [msj2]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 that view
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 6]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 7]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
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).
|
||||
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 up
|
||||
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 as 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 which 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 which is subordinate to another configured
|
||||
trust point MAY be deleted by a resolver after 180 days where such
|
||||
subordinate trust point validly chains to a superior trust point.
|
||||
The decision to delete the subordinate trust anchor is a local
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 8]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
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 a while (i.e. 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
|
||||
Section 2 above
|
||||
|
||||
6.2. Deleting a Trust Anchor
|
||||
|
||||
Assume existing trust anchors 'A' and 'B' and that you want to revoke
|
||||
and delete 'A'.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 9]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
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 which is subordinate to another configured
|
||||
trust point (e.g. example.com to .com) requires some juggling of the
|
||||
data. The specific process is:
|
||||
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
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 10]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
(because the trust point was deleted) or becomes bogus (because it
|
||||
didn't chain to the superior zone).
|
||||
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
The IANA will need to assign a bit in the DNSKEY flags field (see
|
||||
section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
|
||||
IANA actions required.
|
||||
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
In addition to the following sections, see also Theory of Operation
|
||||
above and especially Section 2.2 for related discussions.
|
||||
|
||||
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 trust for 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 outside the scope of this document.
|
||||
|
||||
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
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 11]
|
||||
|
||||
Internet-Draft trustanchor-update November 2006
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Editorial Comments
|
||||
|
||||
[msj2] msj: To be assigned.
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Michael StJohns
|
||||
Nominum, Inc.
|
||||
2385 Bay Road
|
||||
Redwood City, CA 94063
|
||||
USA
|
||||
|
||||
Phone: +1-301-528-4729
|
||||
Email: Mike.StJohns@nominum.com
|
||||
URI: www.nominum.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 12]
|
||||
|
||||
Internet-Draft trustanchor-update November 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.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Expires June 2, 2007 [Page 13]
|
||||
|
||||
|
||||
@@ -1,336 +0,0 @@
|
||||
|
||||
|
||||
|
||||
DNSext Working Group F. Dupont
|
||||
Internet-Draft ISC
|
||||
Updates: 2845,2930,4635 May 8, 2009
|
||||
(if approved)
|
||||
Intended status: Standards Track
|
||||
Expires: November 9, 2009
|
||||
|
||||
|
||||
Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records
|
||||
draft-ietf-dnsext-tsig-md5-deprecated-03.txt
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This Internet-Draft is submitted to IETF in full conformance with the
|
||||
provisions of BCP 78 and BCP 79. This document may contain material
|
||||
from IETF Documents or IETF Contributions published or made publicly
|
||||
available before November 10, 2008. The person(s) controlling the
|
||||
copyright in some of this material may not have granted the IETF
|
||||
Trust the right to allow modifications of such material outside the
|
||||
IETF Standards Process. Without obtaining an adequate license from
|
||||
the person(s) controlling the copyright in such materials, this
|
||||
document may not be modified outside the IETF Standards Process, and
|
||||
derivative works of it may not be created outside the IETF Standards
|
||||
Process, except to format it for publication as an RFC or to
|
||||
translate it into languages other than English.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on November 9, 2009.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2009 IETF Trust and the persons identified as the
|
||||
document authors. All rights reserved.
|
||||
|
||||
|
||||
|
||||
Dupont Expires November 9, 2009 [Page 1]
|
||||
|
||||
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
|
||||
|
||||
|
||||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||||
Provisions Relating to IETF Documents in effect on the date of
|
||||
publication of this document (http://trustee.ietf.org/license-info).
|
||||
Please review these documents carefully, as they describe your rights
|
||||
and restrictions with respect to this document.
|
||||
|
||||
Abstract
|
||||
|
||||
The main purpose of this document is to deprecate the use of HMAC-MD5
|
||||
as an algorithm for the TSIG (secret key transaction authentication)
|
||||
resource record in the DNS (domain name system), and the use of MD5
|
||||
in TKEY (secret key establishment for DNS).
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The secret key transaction authentication for DNS (TSIG, [RFC2845])
|
||||
was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm.
|
||||
When the MD5 [RFC1321] security came to be considered lower than
|
||||
expected, [RFC4635] standardized new TSIG algorithms based on SHA
|
||||
[RFC3174][RFC3874][RFC4634] digests.
|
||||
|
||||
But [RFC4635] did not deprecate the HMAC-MD5 algorithm. This
|
||||
document is targeted to complete the process, in detail:
|
||||
1. Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm
|
||||
name registry managed by the IANA under the IETF Review Policy
|
||||
[RFC5226]
|
||||
2. Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for
|
||||
implementations
|
||||
3. Provide a keying material derivation for the secret key
|
||||
establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman
|
||||
exchange with SHA256 [RFC4634] in place of MD5 [RFC1321]
|
||||
4. Finally recommend the use of HMAC-SHA256.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
|
||||
2. Implementation Requirements
|
||||
|
||||
The table of section 3 of [RFC4635] is replaced by:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dupont Expires November 9, 2009 [Page 2]
|
||||
|
||||
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
|
||||
|
||||
|
||||
+-------------------+--------------------------+
|
||||
| Requirement Level | Algorithm Name |
|
||||
+-------------------+--------------------------+
|
||||
| Optional | HMAC-MD5.SIG-ALG.REG.INT |
|
||||
| Optional | gss-tsig |
|
||||
| Mandatory | hmac-sha1 |
|
||||
| Optional | hmac-sha224 |
|
||||
| Mandatory | hmac-sha256 |
|
||||
| Optional | hmac-sha384 |
|
||||
| Optional | hmac-sha512 |
|
||||
+-------------------+--------------------------+
|
||||
|
||||
Implementations that support TSIG MUST also implement HMAC-SHA1 and
|
||||
HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level)
|
||||
and MAY implement GSS-TSIG and the other algorithms listed above
|
||||
(i.e., algorithms at a "not Mandatory" requirement level).
|
||||
|
||||
|
||||
3. TKEY keying material derivation
|
||||
|
||||
When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying
|
||||
material is derived from the shared secret and TKEY resource record
|
||||
data using MD5 [RFC1321] at the end of section 4.1 page 9.
|
||||
|
||||
This is amended into:
|
||||
|
||||
keying material =
|
||||
XOR ( DH value, SHA256 ( query data | DH value ) |
|
||||
SHA256 ( server data | DH value ) )
|
||||
|
||||
using the same conventions.
|
||||
|
||||
|
||||
4. IANA Consideration
|
||||
|
||||
This document extends the "TSIG Algorithm Names - per [] and
|
||||
[RFC2845]" located at
|
||||
http://www.iana.org/assignments/tsig-algorithm-names by adding a new
|
||||
column to the registry "Compliance Requirement".
|
||||
|
||||
The registry should contain the following:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dupont Expires November 9, 2009 [Page 3]
|
||||
|
||||
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
|
||||
|
||||
|
||||
+--------------------------+------------------------+-------------+
|
||||
| Algorithm Name | Compliance Requirement | Reference |
|
||||
+--------------------------+------------------------+-------------+
|
||||
| gss-tsig | Optional | [RFC3645] |
|
||||
| HMAC-MD5.SIG-ALG.REG.INT | Optional | [][RFC2845] |
|
||||
| hmac-sha1 | Mandatory | [RFC4635] |
|
||||
| hmac-sha224 | Optional | [RFC4635] |
|
||||
| hmac-sha256 | Mandatory | [RFC4635] |
|
||||
| hmac-sha384 | Optional | [RFC4635] |
|
||||
| hmac-sha512 | Optional | [RFC4635] |
|
||||
+--------------------------+------------------------+-------------+
|
||||
|
||||
where [] is this document.
|
||||
|
||||
|
||||
5. Availability Considerations
|
||||
|
||||
MD5 is no longer universally available and its use may lead to
|
||||
increasing operation issues. SHA1 is likely to suffer from the same
|
||||
kind of problem. In summary MD5 has reached end-of-life and SHA1
|
||||
will likely follow in the near term.
|
||||
|
||||
According to [RFC4635], implementations which support TSIG are
|
||||
REQUIRED to implement HMAC-SHA256.
|
||||
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
This document does not assume anything about the cryptographic
|
||||
security of different hash algorithms. Its purpose is a better
|
||||
availability of some security mechanisms in a predictable time frame.
|
||||
|
||||
Requirement levels are adjusted for TSIG and related specifications
|
||||
(i.e., TKEY):
|
||||
The support of HMAC-MD5 is changed from mandatory to optional.
|
||||
The use of MD5 and HMAC-MD5 is NOT RECOMMENDED.
|
||||
The use of HMAC-SHA256 is RECOMMENDED.
|
||||
|
||||
|
||||
7. Acknowledgments
|
||||
|
||||
Olafur Gudmundsson kindly helped in the procedure to deprecate the
|
||||
MD5 use in TSIG, i.e., the procedure which led to this memo. Alfred
|
||||
Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some
|
||||
improvements.
|
||||
|
||||
|
||||
8. References
|
||||
|
||||
|
||||
|
||||
Dupont Expires November 9, 2009 [Page 4]
|
||||
|
||||
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
|
||||
|
||||
|
||||
8.1. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", RFC 2119, BCP 14, March 1997.
|
||||
|
||||
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
|
||||
Wellington, "Secret Key Transaction Authentication for DNS
|
||||
(TSIG)", RFC 2845, May 2000.
|
||||
|
||||
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
|
||||
RR)", RFC 2930, September 2000.
|
||||
|
||||
[RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers",
|
||||
RFC 4635, August 2006.
|
||||
|
||||
8.2. Informative References
|
||||
|
||||
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
|
||||
April 1992.
|
||||
|
||||
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
|
||||
Hashing for Message Authentication", RFC 2104,
|
||||
February 1997.
|
||||
|
||||
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
|
||||
(SHA1)", RFC 3174, September 2001.
|
||||
|
||||
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
|
||||
and R. Hall, "Generic Security Service Algorithm for
|
||||
Secret Key Transaction Authentication for DNS (GSS-TSIG)",
|
||||
RFC 3645, October 2003.
|
||||
|
||||
[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",
|
||||
RFC 3874, September 2004.
|
||||
|
||||
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
|
||||
(SHA and HMAC-SHA)", RFC 4634, July 2006.
|
||||
|
||||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
||||
IANA Considerations Section in RFCs", RFC 5226, BCP 26,
|
||||
May 2008.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dupont Expires November 9, 2009 [Page 5]
|
||||
|
||||
Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Francis Dupont
|
||||
ISC
|
||||
|
||||
Email: Francis.Dupont@fdupont.fr
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dupont Expires November 9, 2009 [Page 6]
|
||||
|
||||
@@ -1,672 +0,0 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group M. Andrews
|
||||
Internet-Draft ISC
|
||||
Intended status: BCP June 5, 2008
|
||||
Expires: December 7, 2008
|
||||
|
||||
|
||||
Locally-served DNS Zones
|
||||
draft-ietf-dnsop-default-local-zones-05
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of 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 December 7, 2008.
|
||||
|
||||
Abstract
|
||||
|
||||
Experience has shown that there are a number of DNS zones all
|
||||
iterative resolvers and recursive nameservers should, unless
|
||||
configured otherwise, automatically serve. RFC 4193 specifies that
|
||||
this should occur for D.F.IP6.ARPA. This document extends the
|
||||
practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space
|
||||
and other well known zones with similar characteristics.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 1]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4
|
||||
3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4
|
||||
4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5
|
||||
4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6
|
||||
4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6
|
||||
4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7
|
||||
5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7
|
||||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
|
||||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
|
||||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
|
||||
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
|
||||
Appendix A. Change History [To Be Removed on Publication] . . . . 10
|
||||
A.1. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 10
|
||||
A.2. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 10
|
||||
A.3. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10
|
||||
A.4. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10
|
||||
A.5. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11
|
||||
A.6. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11
|
||||
A.7. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11
|
||||
A.8. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11
|
||||
Appendix B. Proposed Status [To Be Removed on Publication] . . . 11
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 12
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 2]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Experience has shown that there are a number of DNS [RFC 1034] [RFC
|
||||
1035] zones that all iterative resolvers and recursive nameservers
|
||||
SHOULD, unless intentionally configured otherwise, automatically
|
||||
serve. These zones include, but are not limited to, the IN-ADDR.ARPA
|
||||
zones for the address space allocated by [RFC 1918] and the IP6.ARPA
|
||||
zones for locally assigned unique local IPv6 addresses, [RFC 4193].
|
||||
|
||||
This recommendation is made because data has shown that significant
|
||||
leakage of queries for these name spaces is occurring, despite
|
||||
instructions to restrict them, and because it has therefore become
|
||||
necessary to deploy sacrificial name servers to protect the immediate
|
||||
parent name servers for these zones from excessive, unintentional,
|
||||
query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
|
||||
[I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every
|
||||
expectation that the query load will continue to increase unless
|
||||
steps are taken as outlined here.
|
||||
|
||||
Additionally, queries from clients behind badly configured firewalls
|
||||
that allow outgoing queries for these name spaces but drop the
|
||||
responses, put a significant load on the root servers (forward but no
|
||||
reverse zones configured). They also cause operational load for the
|
||||
root server operators as they have to reply to enquiries about why
|
||||
the root servers are "attacking" these clients. Changing the default
|
||||
configuration will address all these issues for the zones listed in
|
||||
Section 4.
|
||||
|
||||
[RFC 4193] recommends that queries for D.F.IP6.ARPA be handled
|
||||
locally. This document extends the recommendation to cover the IN-
|
||||
ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and
|
||||
IP6.ARPA zones for which queries should not appear on the public
|
||||
Internet.
|
||||
|
||||
It is hoped that by doing this the number of sacrificial servers
|
||||
[AS112] will not have to be increased, and may in time be reduced.
|
||||
|
||||
This recommendation should also help DNS responsiveness for sites
|
||||
which are using [RFC 1918] addresses but do not follow the last
|
||||
paragraph in Section 3 of [RFC 1918].
|
||||
|
||||
1.1. Reserved Words
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC 2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 3]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
2. Effects on sites using RFC 1918 addresses.
|
||||
|
||||
For most sites using [RFC 1918] addresses, the changes here will have
|
||||
little or no detrimental effect. If the site does not already have
|
||||
the reverse tree populated the only effect will be that the name
|
||||
error responses will be generated locally rather than remotely.
|
||||
|
||||
For sites that do have the reverse tree populated, most will either
|
||||
have a local copy of the zones or will be forwarding the queries to
|
||||
servers which have local copies of the zone. Therefore this
|
||||
recommendation will not be relevant.
|
||||
|
||||
The most significant impact will be felt at sites that make use of
|
||||
delegations for [RFC 1918] addresses and have populated these zones.
|
||||
These sites will need to override the default configuration expressed
|
||||
in this document to allow resolution to continue. Typically, such
|
||||
sites will be fully disconnected from the Internet and have their own
|
||||
root servers for their own non-Internet DNS tree.
|
||||
|
||||
|
||||
3. Changes to Iterative Resolver Behaviour.
|
||||
|
||||
Unless configured otherwise, an iterative resolver will now return
|
||||
authoritatively (aa=1) name errors (RCODE=3) for queries within the
|
||||
zones in Section 4, with the obvious exception of queries for the
|
||||
zone name itself where SOA, NS and "no data" responses will be
|
||||
returned as appropriate to the query type. One common way to do this
|
||||
is to serve empty (SOA and NS only) zones.
|
||||
|
||||
An implementation of this recommendation MUST provide a mechanism to
|
||||
disable this new behaviour, and SHOULD allow this decision on a zone
|
||||
by zone basis.
|
||||
|
||||
If using empty zones one SHOULD NOT use the same NS and SOA records
|
||||
as used on the public Internet servers as that will make it harder to
|
||||
detect the origin of the responses and thus any leakage to the public
|
||||
Internet servers. This document recommends that the NS record
|
||||
defaults to the name of the zone and the SOA MNAME defaults to the
|
||||
name of the only NS RR's target. The SOA RNAME should default to
|
||||
"nobody.invalid." [RFC 2606]. Implementations SHOULD provide a
|
||||
mechanism to set these values. No address records need to be
|
||||
provided for the name server.
|
||||
|
||||
Below is an example of a generic empty zone in master file format.
|
||||
It will produce a negative cache TTL of 3 hours.
|
||||
|
||||
@ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
|
||||
@ 10800 IN NS @
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 4]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
The SOA RR is needed to support negative caching [RFC 2308] of name
|
||||
error responses and to point clients to the primary master for DNS
|
||||
dynamic updates.
|
||||
|
||||
SOA values of particular importance are the MNAME, the SOA RR's TTL
|
||||
and the negTTL value. Both TTL values SHOULD match. The rest of the
|
||||
SOA timer values MAY be chosen arbitrarily since they are not
|
||||
intended to control any zone transfer activity.
|
||||
|
||||
The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries
|
||||
to discover the zone to be updated. Having no address records for
|
||||
the name server is expected to abort UPDATE processing in the client.
|
||||
|
||||
|
||||
4. Lists Of Zones Covered
|
||||
|
||||
The following subsections are intended to seed the IANA registry as
|
||||
requested in the IANA Considerations Section. The zone name is the
|
||||
entity to be registered.
|
||||
|
||||
4.1. RFC 1918 Zones
|
||||
|
||||
The following zones correspond to the IPv4 address space reserved in
|
||||
[RFC 1918].
|
||||
|
||||
+----------------------+
|
||||
| Zone |
|
||||
+----------------------+
|
||||
| 10.IN-ADDR.ARPA |
|
||||
| 16.172.IN-ADDR.ARPA |
|
||||
| 17.172.IN-ADDR.ARPA |
|
||||
| 18.172.IN-ADDR.ARPA |
|
||||
| 19.172.IN-ADDR.ARPA |
|
||||
| 20.172.IN-ADDR.ARPA |
|
||||
| 21.172.IN-ADDR.ARPA |
|
||||
| 22.172.IN-ADDR.ARPA |
|
||||
| 23.172.IN-ADDR.ARPA |
|
||||
| 24.172.IN-ADDR.ARPA |
|
||||
| 25.172.IN-ADDR.ARPA |
|
||||
| 26.172.IN-ADDR.ARPA |
|
||||
| 27.172.IN-ADDR.ARPA |
|
||||
| 28.172.IN-ADDR.ARPA |
|
||||
| 29.172.IN-ADDR.ARPA |
|
||||
| 30.172.IN-ADDR.ARPA |
|
||||
| 31.172.IN-ADDR.ARPA |
|
||||
| 168.192.IN-ADDR.ARPA |
|
||||
+----------------------+
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 5]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
4.2. RFC 3330 Zones
|
||||
|
||||
The following zones correspond to those address ranges from [RFC
|
||||
3330] that are not expected to appear as source or destination
|
||||
addresses on the public Internet and to not have a unique name to
|
||||
associate with.
|
||||
|
||||
The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
|
||||
attempt to discourage any practice to provide a PTR RR for
|
||||
1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse
|
||||
mapping should exist, but the exact setup is out of the scope of this
|
||||
document. Similar logic applies to the reverse mapping for ::1
|
||||
(Section 4.3). The recommendations made here simply assume no other
|
||||
coverage for these domains exists.
|
||||
|
||||
+------------------------------+------------------------+
|
||||
| Zone | Description |
|
||||
+------------------------------+------------------------+
|
||||
| 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
|
||||
| 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK |
|
||||
| 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
|
||||
| 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET |
|
||||
| 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
|
||||
+------------------------------+------------------------+
|
||||
|
||||
4.3. Local IPv6 Unicast Addresses
|
||||
|
||||
The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for
|
||||
the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291],
|
||||
Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
|
||||
|
||||
+-------------------------------------------+
|
||||
| Zone |
|
||||
+-------------------------------------------+
|
||||
| 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
|
||||
| 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
|
||||
| 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
|
||||
| 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
|
||||
+-------------------------------------------+
|
||||
|
||||
Note: Line breaks and a escapes '\' have been inserted above for
|
||||
readability and to adhere to line width constraints. They are not
|
||||
parts of the zone names.
|
||||
|
||||
4.4. IPv6 Locally Assigned Local Addresses
|
||||
|
||||
Section 4.4 of [RFC 4193] already required special treatment of:
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 6]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
+--------------+
|
||||
| Zone |
|
||||
+--------------+
|
||||
| D.F.IP6.ARPA |
|
||||
+--------------+
|
||||
|
||||
4.5. IPv6 Link Local Addresses
|
||||
|
||||
IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered
|
||||
by four distinct reverse DNS zones:
|
||||
|
||||
+----------------+
|
||||
| Zone |
|
||||
+----------------+
|
||||
| 8.E.F.IP6.ARPA |
|
||||
| 9.E.F.IP6.ARPA |
|
||||
| A.E.F.IP6.ARPA |
|
||||
| B.E.F.IP6.ARPA |
|
||||
+----------------+
|
||||
|
||||
|
||||
5. Zones that are Out-Of-Scope
|
||||
|
||||
IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and
|
||||
IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered
|
||||
here. It is expected that IPv6 site-local addresses will be self
|
||||
correcting as IPv6 implementations remove support for site-local
|
||||
addresses. However, sacrificial servers for C.E.F.IP6.ARPA through
|
||||
F.E.F.IP6.ARPA may still need to be deployed in the short term if the
|
||||
traffic becomes excessive.
|
||||
|
||||
For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193],
|
||||
there has been no decision made about whether the Regional Internet
|
||||
Registries (RIRs) will provide delegations in this space or not. If
|
||||
they don't, then C.F.IP6.ARPA will need to be added to the list in
|
||||
Section 4.4. If they do, then registries will need to take steps to
|
||||
ensure that name servers are provided for these addresses.
|
||||
|
||||
This document also ignores IP6.INT. IP6.INT has been wound up with
|
||||
only legacy resolvers now generating reverse queries under IP6.INT
|
||||
[RFC 4159].
|
||||
|
||||
This document has also deliberately ignored names immediately under
|
||||
the root domain. While there is a subset of queries to the root name
|
||||
servers which could be addressed using the techniques described here
|
||||
(e.g. .local, .workgroup and IPv4 addresses), there is also a vast
|
||||
amount of traffic that requires a different strategy (e.g. lookups
|
||||
for unqualified hostnames, IPv6 addresses).
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 7]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
This document requests that IANA establish a registry of zones which
|
||||
require this default behaviour. The initial contents of which are in
|
||||
Section 4. Implementors are encouraged to check this registry and
|
||||
adjust their implementations to reflect changes therein.
|
||||
|
||||
This registry can be amended through "IETF Consensus" as per [RFC
|
||||
2434].
|
||||
|
||||
IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
|
||||
deployed in the reverse tree, delegations for these zones are made in
|
||||
the manner described in Section 7.
|
||||
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
During the initial deployment phase, particularly where [RFC 1918]
|
||||
addresses are in use, there may be some clients that unexpectedly
|
||||
receive a name error rather than a PTR record. This may cause some
|
||||
service disruption until their recursive name server(s) have been re-
|
||||
configured.
|
||||
|
||||
As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
|
||||
namespaces, the zones listed above will need to be delegated as
|
||||
insecure delegations, or be within insecure zones. This will allow
|
||||
DNSSEC validation to succeed for queries in these spaces despite not
|
||||
being answered from the delegated servers.
|
||||
|
||||
It is recommended that sites actively using these namespaces secure
|
||||
them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
|
||||
anchors. This will protect the clients from accidental import of
|
||||
unsigned responses from the Internet.
|
||||
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
This work was supported by the US National Science Foundation
|
||||
(research grant SCI-0427144) and DNS-OARC.
|
||||
|
||||
|
||||
9. References
|
||||
|
||||
9.1. Normative References
|
||||
|
||||
[RFC 1034]
|
||||
Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 8]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
[RFC 1035]
|
||||
Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
|
||||
SPECIFICATION", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[RFC 1918]
|
||||
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
|
||||
and E. Lear, "Address Allocation for Private Internets",
|
||||
BCP 5, RFC 1918, February 1996.
|
||||
|
||||
[RFC 2119]
|
||||
Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC 2136]
|
||||
Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
|
||||
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
|
||||
RFC 2136, April 1997.
|
||||
|
||||
[RFC 2308]
|
||||
Andrews, M., "Negative Caching of DNS Queries (DNS
|
||||
NCACHE)", RFC 2398, March 1998.
|
||||
|
||||
[RFC 2434]
|
||||
Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
||||
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
|
||||
October 1998.
|
||||
|
||||
[RFC 2606]
|
||||
Eastlake, D. and A. Panitz, "Reserved Top Level DNS
|
||||
Names", BCP 32, RFC 2606, June 1999.
|
||||
|
||||
[RFC 3596]
|
||||
Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
|
||||
"DNS Extensions to Support IPv6", RFC 3596, October 2003.
|
||||
|
||||
[RFC 4035]
|
||||
Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security
|
||||
Extensions", RFC 4035, March 2005.
|
||||
|
||||
[RFC 4159]
|
||||
Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
|
||||
August 2005.
|
||||
|
||||
[RFC 4193]
|
||||
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
|
||||
Addresses", RFC 4193, October 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 9]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
[RFC 4291]
|
||||
Hinden, R. and S. Deering, "IP Version 6 Addressing
|
||||
Architecture", RFC 4291, February 2006.
|
||||
|
||||
9.2. Informative References
|
||||
|
||||
[AS112] "AS112 Project", <http://www.as112.net/>.
|
||||
|
||||
[I-D.draft-ietf-dnsop-as112-ops]
|
||||
Abley, J. and W. Maton, "AS112 Nameserver Operations",
|
||||
draft-ietf-dnsop-as112-ops-00 (work in progress),
|
||||
February 2007.
|
||||
|
||||
[I-D.draft-ietf-dnsop-as112-under-attack-help-help]
|
||||
Abley, J. and W. Maton, "I'm Being Attacked by
|
||||
PRISONER.IANA.ORG!",
|
||||
draft-ietf-dnsop-as112-under-attack-help-help-00 (work in
|
||||
progress), February 2007.
|
||||
|
||||
[RFC 3330]
|
||||
"Special-Use IPv4 Addresses", RFC 3330, September 2002.
|
||||
|
||||
|
||||
Appendix A. Change History [To Be Removed on Publication]
|
||||
|
||||
A.1. draft-ietf-dnsop-default-local-zones-05.txt
|
||||
|
||||
none, expiry prevention
|
||||
|
||||
A.2. draft-ietf-dnsop-default-local-zones-04.txt
|
||||
|
||||
Centrally Assigned Local addresses -> Non-Locally Assigned Local
|
||||
address
|
||||
|
||||
A.3. draft-ietf-dnsop-default-local-zones-03.txt
|
||||
|
||||
expanded section 4 descriptions
|
||||
|
||||
Added references [RFC 2136], [RFC 3596],
|
||||
[I-D.draft-ietf-dnsop-as112-ops] and
|
||||
[I-D.draft-ietf-dnsop-as112-under-attack-help-help].
|
||||
|
||||
Revised language.
|
||||
|
||||
A.4. draft-ietf-dnsop-default-local-zones-02.txt
|
||||
|
||||
RNAME now "nobody.invalid."
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 10]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
Revised language.
|
||||
|
||||
A.5. draft-ietf-dnsop-default-local-zones-01.txt
|
||||
|
||||
Revised impact description.
|
||||
|
||||
Updated to reflect change in IP6.INT status.
|
||||
|
||||
A.6. draft-ietf-dnsop-default-local-zones-00.txt
|
||||
|
||||
Adopted by DNSOP.
|
||||
|
||||
"Author's Note" re-titled "Zones that are Out-Of-Scope"
|
||||
|
||||
Add note that these zone are expected to seed the IANA registry.
|
||||
|
||||
Title changed.
|
||||
|
||||
A.7. draft-andrews-full-service-resolvers-03.txt
|
||||
|
||||
Added "Proposed Status".
|
||||
|
||||
A.8. draft-andrews-full-service-resolvers-02.txt
|
||||
|
||||
Added 0.IN-ADDR.ARPA.
|
||||
|
||||
|
||||
Appendix B. Proposed Status [To Be Removed on Publication]
|
||||
|
||||
This Internet-Draft is being submitted for eventual publication as an
|
||||
RFC with a proposed status of Best Current Practice.
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Mark P. Andrews
|
||||
Internet Systems Consortium
|
||||
950 Charter Street
|
||||
Redwood City, CA 94063
|
||||
US
|
||||
|
||||
Email: Mark_Andrews@isc.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 11]
|
||||
|
||||
Internet-Draft Locally-served DNS Zones June 2008
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2008).
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Andrews Expires December 7, 2008 [Page 12]
|
||||
|
||||
@@ -1,952 +0,0 @@
|
||||
|
||||
|
||||
|
||||
DNSOP W. Hardaker
|
||||
Internet-Draft Sparta, Inc.
|
||||
Intended status: Informational February 12, 2009
|
||||
Expires: August 16, 2009
|
||||
|
||||
|
||||
Requirements for Management of Name Servers for the DNS
|
||||
draft-ietf-dnsop-name-server-management-reqs-02.txt
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This Internet-Draft is submitted to IETF in full conformance with the
|
||||
provisions of BCP 78 and BCP 79.
|
||||
|
||||
Internet-Drafts are working documents of the Internet Engineering
|
||||
Task Force (IETF), its areas, and its working groups. Note that
|
||||
other groups may also distribute working documents as Internet-
|
||||
Drafts.
|
||||
|
||||
Internet-Drafts are draft documents valid for a maximum of six months
|
||||
and may be updated, replaced, or obsoleted by other documents at any
|
||||
time. It is inappropriate to use Internet-Drafts as reference
|
||||
material or to cite them other than as "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/ietf/1id-abstracts.txt.
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html.
|
||||
|
||||
This Internet-Draft will expire on August 16, 2009.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2009 IETF Trust and the persons identified as the
|
||||
document authors. All rights reserved.
|
||||
|
||||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||||
Provisions Relating to IETF Documents
|
||||
(http://trustee.ietf.org/license-info) in effect on the date of
|
||||
publication of this document. Please review these documents
|
||||
carefully, as they describe your rights and restrictions with respect
|
||||
to this document.
|
||||
|
||||
Abstract
|
||||
|
||||
Management of name servers for the Domain Name Service (DNS) has
|
||||
traditionally been done using vendor-specific monitoring,
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 1]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
configuration and control methods. Although some service monitoring
|
||||
platforms can test the functionality of the DNS itself there is not a
|
||||
interoperable way to manage (monitor, control and configure) the
|
||||
internal aspects of a name server itself.
|
||||
|
||||
This document discusses the requirements of a management system for
|
||||
DNS name servers. A management solution that is designed to manage
|
||||
the DNS can use this document as a shopping list of needed features.
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
|
||||
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5
|
||||
1.1.2. Document Layout and Requirements . . . . . . . . . . . 5
|
||||
2. Management Architecture Requirements . . . . . . . . . . . . . 5
|
||||
2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
|
||||
2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5
|
||||
2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
|
||||
2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
|
||||
2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
|
||||
2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
|
||||
2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
|
||||
2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
|
||||
3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
|
||||
3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
|
||||
3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
|
||||
3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
|
||||
3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
|
||||
3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
|
||||
3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
|
||||
3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
|
||||
3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
|
||||
3.2.5. DNS Protocol Authorization Management . . . . . . . . 9
|
||||
3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
|
||||
3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10
|
||||
4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
|
||||
4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
|
||||
4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
|
||||
4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
|
||||
4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11
|
||||
4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
|
||||
5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
|
||||
5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
|
||||
5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
|
||||
5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 2]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
|
||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
|
||||
8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
|
||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
|
||||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
|
||||
10.2. Informative References . . . . . . . . . . . . . . . . . . 15
|
||||
Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15
|
||||
A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
|
||||
A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
|
||||
A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 3]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Management of name servers for the Domain Name Service (DNS)
|
||||
[RFC1034] [RFC1035] has traditionally been done using vendor-specific
|
||||
monitoring, configuration and control methods. Although some service
|
||||
monitoring platforms can test the functionality of the DNS itself
|
||||
there is not a interoperable way to manage (monitor, control and
|
||||
configure) the internal aspects of a name server itself.
|
||||
|
||||
Previous standardization work within the IETF resulted in the
|
||||
creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
|
||||
to achieve significant implementation and deployment. The perceived
|
||||
reasons behind the failure for the two MIB modules are further
|
||||
documented in [RFC3197].
|
||||
|
||||
This document discusses the requirements of a management system for
|
||||
DNS name servers. A management solution that is designed to manage
|
||||
the DNS can use this document as a shopping list of needed features.
|
||||
|
||||
Specifically out of scope for this document are requirements
|
||||
associated with management of stub resolvers. It is not the intent
|
||||
of this document to document stub resolver requirements, although
|
||||
some of the requirements listed are applicable to stub resolvers as
|
||||
well.
|
||||
|
||||
Also out of scope for this document is management of the host or
|
||||
other components of the host upon which the name server software is
|
||||
running. This document only discusses requirements for managing the
|
||||
name server component of a system.
|
||||
|
||||
The task of creating a management system for managing DNS servers is
|
||||
not expected to be a small one. It is likely that components of the
|
||||
solution will need to be designed in parts over time and these
|
||||
requirements take this into consideration. In particular,
|
||||
Section 5.1 discusses the need for future extensibility of the base
|
||||
management solution. This document is intended to be a road-map
|
||||
towards a desired outcome and is not intended to define an "all-or-
|
||||
nothing" system. Successful interoperable management of name servers
|
||||
even in part is expected to be beneficial to network operators
|
||||
compared to the entirely custom solutions that are used at the time
|
||||
of this writing.
|
||||
|
||||
1.1. Requirements notation
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 4]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
1.1.1. Terminology
|
||||
|
||||
This document is consistent with the terminology defined in Section 2
|
||||
of [RFC4033]. Additional terminology needed for this document is
|
||||
described below:
|
||||
|
||||
Name Server: When we are discussing servers that don't fall into a
|
||||
more specific type of server category defined in other documents,
|
||||
this document will refer to them generically as "name servers".
|
||||
In particular "name servers" can be considered to be any valid
|
||||
combination of authoritative, recursive, validating, or security-
|
||||
aware. The more specific name server labels will be used when
|
||||
this document refers only to a specific type of server. However,
|
||||
the term "name server", in this document, will not include stub
|
||||
resolvers.
|
||||
|
||||
1.1.2. Document Layout and Requirements
|
||||
|
||||
The document is written so that each numbered section will contain
|
||||
only a single requirement if it contains one at all. Each
|
||||
requirement will contain needed wording from the terminology
|
||||
described in Section 1.1. Subsections, however, might exist with
|
||||
additional related requirements. The document is laid out in this
|
||||
way so that a specific requirement can be uniquely referred to using
|
||||
the section number itself and the document version from which it
|
||||
came.
|
||||
|
||||
|
||||
2. Management Architecture Requirements
|
||||
|
||||
This section discusses requirements that reflect the needs of the
|
||||
expected deployment environments.
|
||||
|
||||
2.1. Expected Deployment Scenarios
|
||||
|
||||
DNS zones vary greatly in the type of content published within them.
|
||||
Name Servers, too, are deployed with a wide variety of configurations
|
||||
to support the diversity of the deployed content. It is important
|
||||
that a management solution trying to meet the criteria specified in
|
||||
this document consider supporting the largest number of potential
|
||||
deployment cases as possible. Further deployment scenarios that are
|
||||
not used as direct examples of specific requirements are listed in
|
||||
Appendix A.
|
||||
|
||||
2.1.1. Zone Size Constraints
|
||||
|
||||
The management solution MUST support both name servers that are
|
||||
serving a small number of potentially very large zones (e.g. Top
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 5]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
Level Domains (TLDs)) as well as name servers that are serving a very
|
||||
large number of small zones. These scenarios are both commonly seen
|
||||
deployments.
|
||||
|
||||
2.1.2. Name Server Discovery
|
||||
|
||||
Large enterprise network deployments may contain multiple name
|
||||
servers operating within the boundaries of the enterprise network.
|
||||
These name servers may each be serving multiple zones both in and out
|
||||
of the parent enterprise's zone. Finding and managing large
|
||||
quantities of name servers would be a useful feature of the resulting
|
||||
management solution. The management solution MAY support the ability
|
||||
to discover previously unknown instances of name servers operating
|
||||
within a deployed network.
|
||||
|
||||
2.1.3. Configuration Data Volatility
|
||||
|
||||
Configuration data is defined as data that relates only to the
|
||||
configuration of a server and the zones it serves. It specifically
|
||||
does not include data from the zone contents that is served through
|
||||
DNS itself. The solution MUST support servers that remain fairly
|
||||
statically configured over time as well as servers that have numerous
|
||||
zones being added and removed within an hour. Both of these
|
||||
scenarios are also commonly seen deployments.
|
||||
|
||||
2.1.4. Protocol Selection
|
||||
|
||||
There are many requirements in this document for many different types
|
||||
of management operations (see Section 3 for further details). It is
|
||||
possible that no one protocol will ideally fill all the needs of the
|
||||
requirements listed in this document and thus multiple protocols
|
||||
might be needed to produce a completely functional management system.
|
||||
Multiple protocols might be used to create the complete management
|
||||
solution, but the number of protocols used SHOULD be reduced to a
|
||||
reasonable minimum number.
|
||||
|
||||
2.1.5. Common Data Model
|
||||
|
||||
Defining a standardized protocol (or set of protocols) to use for
|
||||
managing name servers would be a step forward in achieving an
|
||||
interoperable management solution. However, just defining a protocol
|
||||
to use by itself would not achieve the complete end goal of a
|
||||
complete interoperable management solution. Devices also need to
|
||||
represent their internal management interface using a common
|
||||
management data model. The solution MUST create a common data model
|
||||
that management stations can make use of when sending or collecting
|
||||
data from a managed device so it can successfully manage equipment
|
||||
from vendors as if they were generic DNS servers. This common data
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 6]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
model is needed for of the operations discussion in Section 3. Note
|
||||
that this does not preclude the fact that name server vendors might
|
||||
provide additional management infrastructure beyond a base management
|
||||
specification, as discussed further in Section 5.1.
|
||||
|
||||
2.1.6. Operational Impact
|
||||
|
||||
It is impossible to add new features to an existing server (such as
|
||||
the inclusion of a management infrastructure) and not impact the
|
||||
existing service and/or server in some fashion. At a minimum, for
|
||||
example, more memory, disk and/or CPU resources will be required to
|
||||
implement a new management system. However, the impact to the
|
||||
existing DNS service MUST be minimized since the DNS service itself
|
||||
is still the primary service to be offered by the modified name
|
||||
server.
|
||||
|
||||
2.2. Name Server Types
|
||||
|
||||
There are multiple ways in which name servers can be deployed. Name
|
||||
servers can take on any of the following roles:
|
||||
|
||||
o Master Servers
|
||||
|
||||
o Slave Servers
|
||||
|
||||
o Recursive Servers
|
||||
|
||||
The management solution SHOULD support all of these types of name
|
||||
servers as they are all equally important. Note that "Recursive
|
||||
Servers" can be further broken down by the security sub-roles they
|
||||
might implement, as defined in section 2 of [RFC4033]. These sub-
|
||||
roles are also important to support within any management solution.
|
||||
|
||||
As stated earlier, the management of stub resolvers is considered out
|
||||
of scope for this documents.
|
||||
|
||||
|
||||
3. Management Operation Types
|
||||
|
||||
Management operations can traditionally be broken into four
|
||||
categories:
|
||||
|
||||
o Control
|
||||
|
||||
o Configuration
|
||||
|
||||
o Health and Monitoring
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 7]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
o Alarms and Events
|
||||
|
||||
This section discusses requirements for each of these four management
|
||||
types in detail.
|
||||
|
||||
3.1. Control Requirements
|
||||
|
||||
The management solution MUST be capable of performing basic service
|
||||
control operations.
|
||||
|
||||
3.1.1. Needed Control Operations
|
||||
|
||||
These operations SHOULD include, at a minimum, the following
|
||||
operations:
|
||||
|
||||
o Starting the name server
|
||||
|
||||
o Reloading the service configuration
|
||||
|
||||
o Reloading zone data
|
||||
|
||||
o Restarting the name server
|
||||
|
||||
o Stopping the name server
|
||||
|
||||
Note that no restriction is placed on how the management system
|
||||
implements these operations. In particular, at least "starting the
|
||||
name server" will require a minimal management system component to
|
||||
exist independently of the name server itself.
|
||||
|
||||
3.1.2. Asynchronous Status Notifications
|
||||
|
||||
Some control operations might take a long time to complete. As an
|
||||
example, some name servers take a long time to perform reloads of
|
||||
large zones. Because of these timing issues, the management solution
|
||||
SHOULD take this into consideration and offer a mechanism to ease the
|
||||
burden associated with awaiting the status of a long-running command.
|
||||
This could, for example, result in the use of asynchronous
|
||||
notifications for returning the status of a long-running task or it
|
||||
might require the management station to poll for the status of a
|
||||
given task using monitoring commands. These and other potential
|
||||
solutions need to be evaluated carefully to select one that balances
|
||||
the result delivery needs with the perceived implementation costs.
|
||||
|
||||
Also, see the related discussion in Section 3.4 on notification
|
||||
messages for supporting delivery of alarm and event messages.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 8]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
3.2. Configuration Requirements
|
||||
|
||||
Many features of name servers need to be configured before the server
|
||||
can be considered functional. The management solution MUST be able
|
||||
to provide name servers with configuration data. The most important
|
||||
data to be configured, for example, is the served zone data itself.
|
||||
|
||||
3.2.1. Served Zone Modification
|
||||
|
||||
The ability to add, modify and delete zones being served by name
|
||||
servers is needed. Although there are already solutions for zone
|
||||
content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
|
||||
AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
|
||||
might be used as part of the final management solution, the
|
||||
management system SHOULD still be able to natively create a new zone
|
||||
(with enough minimal data to allow the other mechanisms to function
|
||||
as well) as well as delete a zone. This might be, for example, a
|
||||
management operation that at least allows for the creation of the
|
||||
initial SOA record for a new zone as that's the minimum amount of
|
||||
zone data needed for the other operations to function.
|
||||
|
||||
3.2.2. Trust Anchor Management
|
||||
|
||||
The solution SHOULD support the ability to add, modify and delete
|
||||
trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
|
||||
[RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust
|
||||
anchors might be configured using the data from the DNSKEY Resource
|
||||
Records (RRs) themselves or by using Delegation Signer (DS)
|
||||
fingerprints.
|
||||
|
||||
3.2.3. Security Expectations
|
||||
|
||||
DNSSEC Validating resolvers need to make policy decisions about the
|
||||
requests being processed. For example, they need to be configured
|
||||
with a list of zones expected to be secured by DNSSEC. The
|
||||
management solution SHOULD be able to add, modify and delete
|
||||
attributes of DNSSEC security policies.
|
||||
|
||||
3.2.4. TSIG Key Management
|
||||
|
||||
TSIG [RFC2845] allows transaction level authentication of DNS
|
||||
traffic. The management solution SHOULD be able to add, modify and
|
||||
delete TSIG keys known to the name server.
|
||||
|
||||
3.2.5. DNS Protocol Authorization Management
|
||||
|
||||
The management solution SHOULD have the ability to add, modify and
|
||||
delete authorization settings for the DNS protocols itself. Do not
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 9]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
confuse this with the ability to manage the authorization associated
|
||||
with the management protocol itself, which is discussed later in
|
||||
Section 4.4. There are a number of authorization settings that are
|
||||
used by a name server. Example authorization settings that the
|
||||
solution might need to cover are:
|
||||
|
||||
o Access to operations on zone data (e.g. DDNS)
|
||||
|
||||
o Access to certain zone data from certain sources (e.g. from
|
||||
particular network subnets)
|
||||
|
||||
o Access to specific DNS protocol services (e.g. recursive service)
|
||||
|
||||
Note: the above list is expected to be used as a collection of
|
||||
examples and is not a complete list of needed authorization
|
||||
protections.
|
||||
|
||||
3.3. Monitoring Requirements
|
||||
|
||||
Monitoring is the process of collecting aspects of the internal state
|
||||
of a name server at a given moment in time. The solution MUST be
|
||||
able to monitor the health of a name server to determine its
|
||||
operational status, load and other internal attributes. Example
|
||||
management tasks that the solution might need to cover are:
|
||||
|
||||
o Number of requests sent, responses sent, average response latency
|
||||
and other performance counters
|
||||
|
||||
o Server status (e.g. "serving data", "starting up", "shutting
|
||||
down", ...)
|
||||
|
||||
o Access control violations
|
||||
|
||||
o List of zones being served
|
||||
|
||||
o Detailed statistics about clients interacting with the name server
|
||||
(e.g. top 10 clients requesting data).
|
||||
|
||||
Note: the above list is expected to be used as a collection of
|
||||
examples and is not a complete list of needed monitoring operations.
|
||||
In particular, some monitoring statistics are expected to be
|
||||
computationally or resource expensive and are considered to be "nice
|
||||
to haves" as opposed to "necessary to have".
|
||||
|
||||
3.4. Alarm and Event Requirements
|
||||
|
||||
Events occurring at the name server that trigger alarm notifications
|
||||
can quickly inform a management station about critical issues. A
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 10]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
management solution SHOULD include support for delivery of alarm
|
||||
conditions.
|
||||
|
||||
Example alarm conditions might include:
|
||||
|
||||
o The server's status is changing. (e.g it is starting up, reloading
|
||||
configuration, restarting or shutting down)
|
||||
|
||||
o A needed resource (e.g. memory or disk space) is exhausted or
|
||||
nearing exhaustion
|
||||
|
||||
o An authorization violation was detected
|
||||
|
||||
o The server has not received any data traffic (e.g. DNS requests
|
||||
or NOTIFYs) recently (AKA the "lonely warning"). This condition
|
||||
might indicate a problem with its deployment.
|
||||
|
||||
|
||||
4. Security Requirements
|
||||
|
||||
The management solution will need to be appropriately secured against
|
||||
attacks on the management infrastructure.
|
||||
|
||||
4.1. Authentication
|
||||
|
||||
The solution MUST support mutual authentication. The management
|
||||
client needs to be assured that the management operations are being
|
||||
transferred to and from the correct name server. The managed name
|
||||
server needs to authenticate the system that is accessing the
|
||||
management infrastructure within itself.
|
||||
|
||||
4.2. Integrity Protection
|
||||
|
||||
Management operations MUST be protected from modification while in
|
||||
transit from the management client to the server.
|
||||
|
||||
4.3. Confidentiality
|
||||
|
||||
The management solution MUST support message confidentiality. The
|
||||
potential transfer of sensitive configuration is expected (such as
|
||||
TSIG keys or security policies). The solution does not, however,
|
||||
necessarily need to provide confidentiality to data that would
|
||||
normally be carried without confidentiality by the DNS system itself.
|
||||
|
||||
4.4. Authorization
|
||||
|
||||
The solution SHOULD be capable of providing a fine-grained
|
||||
authorization model for any management protocols it introduces to the
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 11]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
completed system. This authorization differs from the authorization
|
||||
previously discussed in Section 3.2.5 in that this requirement is
|
||||
concerned solely with authorization of the management system itself.
|
||||
|
||||
There are a number of authorization settings that might be used by a
|
||||
managed system to determine whether the managing entity has
|
||||
authorization to perform the given management task. Example
|
||||
authorization settings that the solution might need to cover are:
|
||||
|
||||
o Access to the configuration that specifies which zones are to be
|
||||
served
|
||||
|
||||
o Access to the management system infrastructure
|
||||
|
||||
o Access to other control operations
|
||||
|
||||
o Access to other configuration operations
|
||||
|
||||
o Access to monitoring operations
|
||||
|
||||
Note: the above list is expected to be used as a collection of
|
||||
examples and is not a complete list of needed authorization
|
||||
protections.
|
||||
|
||||
4.5. Solution Impacts on Security
|
||||
|
||||
The solution MUST minimize the security risks introduced to the
|
||||
complete name server system. It is impossible to add new
|
||||
infrastructure to a server and not impact the security in some
|
||||
fashion as the introduction of a management protocol alone will
|
||||
provide a new avenue for potential attack. Although the added
|
||||
management benefits will be worth the increased risks, the solution
|
||||
still needs to minimize this impact as much as possible.
|
||||
|
||||
|
||||
5. Other Requirements
|
||||
|
||||
5.1. Extensibility
|
||||
|
||||
The management solution is expected to change and expand over time as
|
||||
lessons are learned and new DNS features are deployed. Thus, the
|
||||
solution MUST be flexible and be able to accommodate new future
|
||||
management operations. The solution might, for example, make use of
|
||||
protocol versioning or capability description exchanges to ensure
|
||||
that management stations and name servers that weren't written to the
|
||||
same specification version can still interoperate to the best of
|
||||
their combined ability.
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 12]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
5.1.1. Vendor Extensions
|
||||
|
||||
It MUST be possible for vendors to extend the standardized management
|
||||
model with vendor-specific extensions to support additional features
|
||||
offered by their products.
|
||||
|
||||
5.1.2. Extension Identification
|
||||
|
||||
It MUST be possible for a management station to understand which
|
||||
parts of returned data are specific to a given vendor or other
|
||||
standardized extension. The data returned needs to be appropriately
|
||||
marked through the use of name spaces or similar mechanisms to ensure
|
||||
that the base management model data can be logically separated from
|
||||
extension data without needing to understand the extension data
|
||||
itself.
|
||||
|
||||
5.1.3. Name-Space Collision Protection
|
||||
|
||||
It MUST be possible to protect against multiple extensions
|
||||
conflicting with each other. The use of name-space protection
|
||||
mechanisms for communicated management variables is common practice
|
||||
to protect against problems. Name-space identification techniques
|
||||
also frequently solve the "Extension Identification" requirement
|
||||
discussed in Section 5.1.2 as well.
|
||||
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
Any management protocol that meets the criteria discussed in this
|
||||
document needs to support the criteria discussed in Section 4 in
|
||||
order to protect the management infrastructure itself. The DNS is a
|
||||
core Internet service and management traffic that protects it could
|
||||
be the target of attacks designed to subvert that service. Because
|
||||
the management infrastructure will be adding additional interfaces to
|
||||
that service, it is critical that the management infrastructure
|
||||
support adequate protections against network attacks.
|
||||
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
No action is required from IANA for this document.
|
||||
|
||||
|
||||
8. Document History
|
||||
|
||||
A requirement gathering discussion was held at the December 2007 IETF
|
||||
meeting in Vancouver, BC, Canada and a follow up meeting was held at
|
||||
the March 2008 IETF meeting in Philadelphia. This document is a
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 13]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
compilation of the results of those discussions as well as
|
||||
discussions on the DCOMA mailing list.
|
||||
|
||||
|
||||
9. Acknowledgments
|
||||
|
||||
This draft is the result of discussions within the DCOMA design team
|
||||
chaired by Jaap Akkerhuis. This team consisted of a large number of
|
||||
people all of whom provided valuable insight and input into the
|
||||
discussions surrounding name server management. The text of this
|
||||
document was written from notes taken during meetings as well as from
|
||||
contributions sent to the DCOMA mailing list. This work documents
|
||||
the consensus of the DCOMA design team.
|
||||
|
||||
In particular, the following team members contributed significantly
|
||||
to the text in the document:
|
||||
|
||||
Stephane Bortzmeyer
|
||||
|
||||
Stephen Morris
|
||||
|
||||
Phil Regnauld
|
||||
|
||||
Further editing contributions and wording suggestions were made by:
|
||||
Alfred Hoenes.
|
||||
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
||||
[RFC1035] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
|
||||
August 1996.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
|
||||
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
|
||||
RFC 2136, April 1997.
|
||||
|
||||
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 14]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
Wellington, "Secret Key Transaction Authentication for DNS
|
||||
(TSIG)", RFC 2845, May 2000.
|
||||
|
||||
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
|
||||
Update", RFC 3007, November 2000.
|
||||
|
||||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements",
|
||||
RFC 4033, March 2005.
|
||||
|
||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions",
|
||||
RFC 4034, March 2005.
|
||||
|
||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security
|
||||
Extensions", RFC 4035, March 2005.
|
||||
|
||||
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
|
||||
(DS) Resource Records (RRs)", RFC 4509, May 2006.
|
||||
|
||||
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
|
||||
Trust Anchors", RFC 5011, September 2007.
|
||||
|
||||
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
|
||||
Security (DNSSEC) Hashed Authenticated Denial of
|
||||
Existence", RFC 5155, March 2008.
|
||||
|
||||
10.2. Informative References
|
||||
|
||||
[RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
|
||||
RFC 1611, May 1994.
|
||||
|
||||
[RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
|
||||
RFC 1612, May 1994.
|
||||
|
||||
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
|
||||
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
|
||||
July 1997.
|
||||
|
||||
[RFC3197] Austein, R., "Applicability Statement for DNS MIB
|
||||
Extensions", RFC 3197, November 2001.
|
||||
|
||||
|
||||
Appendix A. Deployment Scenarios
|
||||
|
||||
This appendix documents some additional deployment scenarios that
|
||||
have been traditionally difficult to manage. They are provided as
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 15]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
guidance to protocol developers as data points of real-world name
|
||||
server management problems.
|
||||
|
||||
A.1. Non-Standard Zones
|
||||
|
||||
If an organization uses non-standard zones (for example a purely-
|
||||
local TLD), synchronizing all the name servers for these zones is
|
||||
usually a time-consuming task. It is made worse when two
|
||||
organizations with conflicting zones merge. This situation is not a
|
||||
recommended deployment scenario (and is even heavily discouraged) but
|
||||
it is, unfortunately, seen in the wild.
|
||||
|
||||
It is typically implemented using "forwarding" zones. But there is
|
||||
no way to ensure automatically that all the resolvers have the same
|
||||
set of zones to forward at any given time. New zones might be added
|
||||
to a local forwarding recursive server, for example, without
|
||||
modifying the rest of the deployed forwarding servers. It is hoped
|
||||
that a management solution which could handle the configuration of
|
||||
zone forwarding would finally allow management of servers deployed in
|
||||
this fashion.
|
||||
|
||||
A.2. Redundancy Sharing
|
||||
|
||||
For reliability reasons it is recommended that zone operators follow
|
||||
the guidelines documented in [RFC2182] which recommends that multiple
|
||||
name servers be configured for each zone and that the name servers
|
||||
are separated both physically and via connectivity routes. A common
|
||||
solution is to establish DNS-serving partnerships: "I'll host your
|
||||
zones and you'll host mine". Both entities benefit from increased
|
||||
DNS reliability via the wider service distribution. This frequently
|
||||
occurs between cooperating but otherwise unrelated entities (such as
|
||||
between two distinct companies) as well as between affiliated
|
||||
organizations (such as between branch offices within a single
|
||||
company).
|
||||
|
||||
The configuration of these relationships are currently required to be
|
||||
manually configured and maintained. Changes to the list of zones
|
||||
that are cross-hosted are manually negotiated between the cooperating
|
||||
network administrators and configured by hand. A management protocol
|
||||
with the ability to provide selective authorization, as discussed in
|
||||
Section 4.4, would solve many of the management difficulties between
|
||||
cooperating organizations.
|
||||
|
||||
A.3. DNSSEC Management
|
||||
|
||||
There are many different DNSSEC deployment strategies that may be
|
||||
used for mission-critical zones. The following list describes some
|
||||
example deployment scenarios that might warrant different management
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 16]
|
||||
|
||||
Internet-Draft Name Server Management Requirements February 2009
|
||||
|
||||
|
||||
strategies.
|
||||
|
||||
All contents and DNSSEC keying information controlled and operated
|
||||
by a single organization
|
||||
|
||||
Zone contents controlled and operated by one organization, all
|
||||
DNSSEC keying information controlled and operated by a second
|
||||
organization.
|
||||
|
||||
Zone contents controlled and operated by one organization, zone
|
||||
signing keys (ZSKs) controlled and operated by a second
|
||||
organization, and key signing keys (KSKs) controlled and operated
|
||||
by a third organization.
|
||||
|
||||
Although this list is not exhaustive in the potential ways that zone
|
||||
data can be divided up, it should be sufficient to illustrate the
|
||||
potential ways in which zone data can be controlled by multiple
|
||||
entities.
|
||||
|
||||
The end result of all of these strategies, however, will be the same:
|
||||
a live zone containing DNSSEC related resource records. Many of the
|
||||
above strategies are merely different ways of preparing a zone for
|
||||
serving. A management solution that includes support for managing
|
||||
DNSSEC zone data may wish to take into account these potential
|
||||
management scenarios.
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Wes Hardaker
|
||||
Sparta, Inc.
|
||||
P.O. Box 382
|
||||
Davis, CA 95617
|
||||
US
|
||||
|
||||
Phone: +1 530 792 1913
|
||||
Email: ietf@hardakers.net
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hardaker Expires August 16, 2009 [Page 17]
|
||||
|
||||
@@ -1,640 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DNSOP Working Group Paul Vixie, ISC
|
||||
INTERNET-DRAFT Akira Kato, WIDE
|
||||
<draft-ietf-dnsop-respsize-06.txt> August 2006
|
||||
|
||||
DNS Referral Response Size Issues
|
||||
|
||||
Status of this Memo
|
||||
By submitting this Internet-Draft, each author represents that any
|
||||
applicable patent or other IPR claims of which he or she is aware
|
||||
have been or will be disclosed, and any of which he or she becomes
|
||||
aware will be disclosed, in accordance with Section 6 of 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.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006). All Rights Reserved.
|
||||
|
||||
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
With a mandated default minimum maximum message size of 512 octets,
|
||||
the DNS protocol presents some special problems for zones wishing to
|
||||
expose a moderate or high number of authority servers (NS RRs). This
|
||||
document explains the operational issues caused by, or related to
|
||||
this response size limit, and suggests ways to optimize the use of
|
||||
this limited space. Guidance is offered to DNS server implementors
|
||||
and to DNS zone operators.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 1]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
1 - Introduction and Overview
|
||||
|
||||
1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
|
||||
octets. Even though this limitation was due to the required minimum IP
|
||||
reassembly limit for IPv4, it became a hard DNS protocol limit and is
|
||||
not implicitly relaxed by changes in transport, for example to IPv6.
|
||||
|
||||
1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
|
||||
larger responses by mutual agreement of the requester and responder.
|
||||
The 512 octet message size limit will remain in practical effect until
|
||||
there is widespread deployment of EDNS0 in DNS resolvers on the
|
||||
Internet.
|
||||
|
||||
1.3. Since DNS responses include a copy of the request, the space
|
||||
available for response data is somewhat less than the full 512 octets.
|
||||
Negative responses are quite small, but for positive and delegation
|
||||
responses, every octet must be carefully and sparingly allocated. This
|
||||
document specifically addresses delegation response sizes.
|
||||
|
||||
2 - Delegation Details
|
||||
|
||||
2.1. RELEVANT PROTOCOL ELEMENTS
|
||||
|
||||
2.1.1. A delegation response will include the following elements:
|
||||
|
||||
Header Section: fixed length (12 octets)
|
||||
Question Section: original query (name, class, type)
|
||||
Answer Section: empty, or a CNAME/DNAME chain
|
||||
Authority Section: NS RRset (nameserver names)
|
||||
Additional Section: A and AAAA RRsets (nameserver addresses)
|
||||
|
||||
2.1.2. If the total response size exceeds 512 octets, and if the data
|
||||
that does not fit was "required", then the TC bit will be set
|
||||
(indicating truncation). This will usually cause the requester to retry
|
||||
using TCP, depending on what information was desired and what
|
||||
information was omitted. For example, truncation in the authority
|
||||
section is of no interest to a stub resolver who only plans to consume
|
||||
the answer section. If a retry using TCP is needed, the total cost of
|
||||
the transaction is much higher. See [RFC1123 6.1.3.2] for details on
|
||||
the requirement that UDP be attempted before falling back to TCP.
|
||||
|
||||
2.1.3. RRsets are never sent partially unless TC bit set to indicate
|
||||
truncation. When TC bit is set, the final apparent RRset in the final
|
||||
non-empty section must be considered "possibly damaged" (see [RFC1035
|
||||
6.2], [RFC2181 9]).
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 2]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
2.1.4. With or without truncation, the glue present in the additional
|
||||
data section should be considered "possibly incomplete", and requesters
|
||||
should be prepared to re-query for any damaged or missing RRsets. Note
|
||||
that truncation of the additional data section might not be signalled
|
||||
via the TC bit since additional data is often optional (see discussion
|
||||
in [RFC4472 B]).
|
||||
|
||||
2.1.5. DNS label compression allows a domain name to be instantiated
|
||||
only once per DNS message, and then referenced with a two-octet
|
||||
"pointer" from other locations in that same DNS message (see [RFC1035
|
||||
4.1.4]). If all nameserver names in a message share a common parent
|
||||
(for example, all ending in ".ROOT-SERVERS.NET"), then more space will
|
||||
be available for incompressable data (such as nameserver addresses).
|
||||
|
||||
2.1.6. The query name can be as long as 255 octets of network data. In
|
||||
this worst case scenario, the question section will be 259 octets in
|
||||
size, which would leave only 240 octets for the authority and additional
|
||||
sections (after deducting 12 octets for the fixed length header.)
|
||||
|
||||
2.2. ADVICE TO ZONE OWNERS
|
||||
|
||||
2.2.1. Average and maximum question section sizes can be predicted by
|
||||
the zone owner, since they will know what names actually exist, and can
|
||||
measure which ones are queried for most often. Note that if the zone
|
||||
contains any wildcards, it is possible for maximum length queries to
|
||||
require positive responses, but that it is reasonable to expect
|
||||
truncation and TCP retry in that case. For cost and performance
|
||||
reasons, the majority of requests should be satisfied without truncation
|
||||
or TCP retry.
|
||||
|
||||
2.2.2. Some queries to non-existing names can be large, but this is not
|
||||
a problem because negative responses need not contain any answer,
|
||||
authority or additional records. See [RFC2308 2.1] for more information
|
||||
about the format of negative responses.
|
||||
|
||||
2.2.3. The minimum useful number of name servers is two, for redundancy
|
||||
(see [RFC1034 4.1]). A zone's name servers should be reachable by all
|
||||
IP transport protocols (e.g., IPv4 and IPv6) in common use.
|
||||
|
||||
2.2.4. The best case is no truncation at all. This is because many
|
||||
requesters will retry using TCP immediately, or will automatically re-
|
||||
query for RRsets that are possibly truncated, without considering
|
||||
whether the omitted data was actually necessary.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 3]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
2.3. ADVICE TO SERVER IMPLEMENTORS
|
||||
|
||||
2.3.1. In case of multi-homed name servers, it is advantageous to
|
||||
include an address record from each of several name servers before
|
||||
including several address records for any one name server. If address
|
||||
records for more than one transport (for example, A and AAAA) are
|
||||
available, then it is advantageous to include records of both types
|
||||
early on, before the message is full.
|
||||
|
||||
2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
|
||||
class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
|
||||
Each A RR will require 16 octets, and each AAAA RR will require 28
|
||||
octets.
|
||||
|
||||
2.3.3. While DNS distinguishes between necessary and optional resource
|
||||
records, this distinction is according to protocol elements necessary to
|
||||
signify facts, and takes no official notice of protocol content
|
||||
necessary to ensure correct operation. For example, a nameserver name
|
||||
that is in or below the zone cut being described by a delegation is
|
||||
"necessary content," since there is no way to reach that zone unless the
|
||||
parent zone's delegation includes "glue records" describing that name
|
||||
server's addresses.
|
||||
|
||||
2.3.4. It is also necessary to distinguish between "explicit truncation"
|
||||
where a message could not contain enough records to convey its intended
|
||||
meaning, and so the TC bit has been set, and "silent truncation", where
|
||||
the message was not large enough to contain some records which were "not
|
||||
required", and so the TC bit was not set.
|
||||
|
||||
2.3.5. A delegation response should prioritize glue records as follows.
|
||||
|
||||
first
|
||||
All glue RRsets for one name server whose name is in or below the
|
||||
zone being delegated, or which has multiple address RRsets (currently
|
||||
A and AAAA), or preferably both;
|
||||
|
||||
second
|
||||
Alternate between adding all glue RRsets for any name servers whose
|
||||
names are in or below the zone being delegated, and all glue RRsets
|
||||
for any name servers who have multiple address RRsets (currently A
|
||||
and AAAA);
|
||||
|
||||
thence
|
||||
All other glue RRsets, in any order.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 4]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
Whenever there are multiple candidates for a position in this priority
|
||||
scheme, one should be chosen on a round-robin or fully random basis.
|
||||
|
||||
The goal of this priority scheme is to offer "necessary" glue first,
|
||||
avoiding silent truncation for this glue if possible.
|
||||
|
||||
2.3.6. If any "necessary content" is silently truncated, then it is
|
||||
advisable that the TC bit be set in order to force a TCP retry, rather
|
||||
than have the zone be unreachable. Note that a parent server's proper
|
||||
response to a query for in-child glue or below-child glue is a referral
|
||||
rather than an answer, and that this referral MUST be able to contain
|
||||
the in-child or below-child glue, and that in outlying cases, only EDNS
|
||||
or TCP will be large enough to contain that data.
|
||||
|
||||
3 - Analysis
|
||||
|
||||
3.1. An instrumented protocol trace of a best case delegation response
|
||||
follows. Note that 13 servers are named, and 13 addresses are given.
|
||||
This query was artificially designed to exactly reach the 512 octet
|
||||
limit.
|
||||
|
||||
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
|
||||
;; QUERY SECTION:
|
||||
;; [23456789.123456789.123456789.\
|
||||
123456789.123456789.123456789.com A IN] ;; @80
|
||||
|
||||
;; AUTHORITY SECTION:
|
||||
com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
|
||||
com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
|
||||
com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
|
||||
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
|
||||
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
|
||||
com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
|
||||
com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
|
||||
com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
|
||||
com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
|
||||
com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
|
||||
com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
|
||||
com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
|
||||
com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 5]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
;; ADDITIONAL SECTION:
|
||||
A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
|
||||
B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
|
||||
C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
|
||||
D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
|
||||
E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
|
||||
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
|
||||
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
|
||||
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
|
||||
I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
|
||||
J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
|
||||
K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
|
||||
L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
|
||||
M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
|
||||
|
||||
;; MSG SIZE sent: 80 rcvd: 512
|
||||
|
||||
3.2. For longer query names, the number of address records supplied will
|
||||
be lower. Furthermore, it is only by using a common parent name (which
|
||||
is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
|
||||
fit, due to the use of DNS compression pointers in the last 12
|
||||
occurances of the parent domain name. The following output from a
|
||||
response simulator demonstrates these properties.
|
||||
|
||||
% perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
|
||||
a.dns.br requires 10 bytes
|
||||
b.dns.br requires 4 bytes
|
||||
c.dns.br requires 4 bytes
|
||||
d.dns.br requires 4 bytes
|
||||
# of NS: 4
|
||||
For maximum size query (255 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 3 (yellow)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
|
||||
For average size query (64 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 4 (green)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 6]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
% perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
|
||||
ns-ext.isc.org requires 16 bytes
|
||||
ns.psg.com requires 12 bytes
|
||||
ns.ripe.net requires 13 bytes
|
||||
ns.eu.int requires 11 bytes
|
||||
# of NS: 4
|
||||
For maximum size query (255 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 3 (yellow)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
|
||||
For average size query (64 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 4 (green)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
|
||||
|
||||
(Note: The response simulator program is shown in Section 5.)
|
||||
|
||||
Here we use the term "green" if all address records could fit, or
|
||||
"yellow" if two or more could fit, or "orange" if only one could fit, or
|
||||
"red" if no address record could fit. It's clear that without a common
|
||||
parent for nameserver names, much space would be lost. For these
|
||||
examples we use an average/common name size of 15 octets, befitting our
|
||||
assumption of GTLD-SERVERS.NET as our common parent name.
|
||||
|
||||
We're assuming a medium query name size of 64 since that is the typical
|
||||
size seen in trace data at the time of this writing. If
|
||||
Internationalized Domain Name (IDN) or any other technology which
|
||||
results in larger query names be deployed significantly in advance of
|
||||
EDNS, then new measurements and new estimates will have to be made.
|
||||
|
||||
4 - Conclusions
|
||||
|
||||
4.1. The current practice of giving all nameserver names a common parent
|
||||
(such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
|
||||
responses and allows for more nameservers to be enumerated than would
|
||||
otherwise be possible, since the common parent domain name only appears
|
||||
once in a DNS message and is referred to via "compression pointers"
|
||||
thereafter.
|
||||
|
||||
4.2. If all nameserver names for a zone share a common parent, then it
|
||||
is operationally advisable to make all servers for the zone thus served
|
||||
also be authoritative for the zone of that common parent. For example,
|
||||
the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
|
||||
for the ROOT-SERVERS.NET. This is to ensure that the zone's servers
|
||||
always have the zone's nameservers' glue available when delegating, and
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 7]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
will be able to respond with answers rather than referrals if a
|
||||
requester who wants that glue comes back asking for it. In this case
|
||||
the name server will likely be a "stealth server" -- authoritative but
|
||||
unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more
|
||||
information about stealth servers.
|
||||
|
||||
4.3. Thirteen (13) is the effective maximum number of nameserver names
|
||||
usable traditional (non-extended) DNS, assuming a common parent domain
|
||||
name, and given that implicit referral response truncation is
|
||||
undesirable in the average case.
|
||||
|
||||
4.4. Multi-homing of name servers within a protocol family is
|
||||
inadvisable since the necessary glue RRsets (A or AAAA) are atomically
|
||||
indivisible, and will be larger than a single resource record. Larger
|
||||
RRsets are more likely to lead to or encounter truncation.
|
||||
|
||||
4.5. Multi-homing of name servers across protocol families is less
|
||||
likely to lead to or encounter truncation, partly because multiprotocol
|
||||
clients are more likely to speak EDNS which can use a larger response
|
||||
size limit, and partly because the resource records (A and AAAA) are in
|
||||
different RRsets and are therefore divisible from each other.
|
||||
|
||||
4.6. Name server names which are at or below the zone they serve are
|
||||
more sensitive to referral response truncation, and glue records for
|
||||
them should be considered "less optional" than other glue records, in
|
||||
the assembly of referral responses.
|
||||
|
||||
4.7. If a zone is served by thirteen (13) name servers having a common
|
||||
parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
|
||||
single address record in some protocol family (e.g., an A RR), then all
|
||||
thirteen name servers or any subset thereof could multi-home in a second
|
||||
protocol family by adding a second address record (e.g., an AAAA RR)
|
||||
without reducing the reachability of the zone thus served.
|
||||
|
||||
5 - Source Code
|
||||
|
||||
#!/usr/bin/perl
|
||||
#
|
||||
# SYNOPSIS
|
||||
# repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
|
||||
# if all queries are assumed to have a same zone suffix,
|
||||
# such as "jp" in JP TLD servers, specify it in -z option
|
||||
#
|
||||
use strict;
|
||||
use Getopt::Std;
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 8]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
my ($sz_msg) = (512);
|
||||
my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
|
||||
my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
|
||||
my (%namedb, $name, $nssect, %opts, $optz);
|
||||
my $n_ns = 0;
|
||||
|
||||
getopt('z', %opts);
|
||||
if (defined($opts{'z'})) {
|
||||
server_name_len($opts{'z'}); # just register it
|
||||
}
|
||||
|
||||
foreach $name (@ARGV) {
|
||||
my $len;
|
||||
$n_ns++;
|
||||
$len = server_name_len($name);
|
||||
print "$name requires $len bytes\n";
|
||||
$nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
|
||||
+ $sz_rdlen + $len;
|
||||
}
|
||||
print "# of NS: $n_ns\n";
|
||||
arsect(255, $nssect, $n_ns, "maximum");
|
||||
arsect(64, $nssect, $n_ns, "average");
|
||||
|
||||
sub server_name_len {
|
||||
my ($name) = @_;
|
||||
my (@labels, $len, $n, $suffix);
|
||||
|
||||
$name =~ tr/A-Z/a-z/;
|
||||
@labels = split(/\./, $name);
|
||||
$len = length(join('.', @labels)) + 2;
|
||||
for ($n = 0; $#labels >= 0; $n++, shift @labels) {
|
||||
$suffix = join('.', @labels);
|
||||
return length($name) - length($suffix) + $sz_ptr
|
||||
if (defined($namedb{$suffix}));
|
||||
$namedb{$suffix} = 1;
|
||||
}
|
||||
return $len;
|
||||
}
|
||||
|
||||
sub arsect {
|
||||
my ($sz_query, $nssect, $n_ns, $cond) = @_;
|
||||
my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
|
||||
$ansect = $sz_query + 1 + $sz_type + $sz_class;
|
||||
$space = $sz_msg - $sz_header - $ansect - $nssect;
|
||||
$n_a = atmost(int($space / $sz_rr_a), $n_ns);
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 9]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
$n_a_aaaa = atmost(int($space
|
||||
/ ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
|
||||
$n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
|
||||
/ $sz_rr_aaaa), $n_ns);
|
||||
printf "For %s size query (%d byte):\n", $cond, $sz_query;
|
||||
printf " only A is considered: ";
|
||||
printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
|
||||
printf " A and AAAA are considered: ";
|
||||
printf "# of A+AAAA is %d (%s)\n",
|
||||
$n_a_aaaa, &judge($n_a_aaaa, $n_ns);
|
||||
printf " preferred-glue A is assumed: ";
|
||||
printf "# of A is %d, # of AAAA is %d (%s)\n",
|
||||
$n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
|
||||
}
|
||||
|
||||
sub judge {
|
||||
my ($n, $n_ns) = @_;
|
||||
return "green" if ($n >= $n_ns);
|
||||
return "yellow" if ($n >= 2);
|
||||
return "orange" if ($n == 1);
|
||||
return "red";
|
||||
}
|
||||
|
||||
sub atmost {
|
||||
my ($a, $b) = @_;
|
||||
return 0 if ($a < 0);
|
||||
return $b if ($a > $b);
|
||||
return $a;
|
||||
}
|
||||
|
||||
6 - Security Considerations
|
||||
|
||||
The recommendations contained in this document have no known security
|
||||
implications.
|
||||
|
||||
7 - IANA Considerations
|
||||
|
||||
This document does not call for changes or additions to any IANA
|
||||
registry.
|
||||
|
||||
8 - Acknowledgement
|
||||
|
||||
The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
|
||||
for their valuable comments and suggestions.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 10]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
This work was supported by the US National Science Foundation (research
|
||||
grant SCI-0427144) and DNS-OARC.
|
||||
|
||||
9 - References
|
||||
|
||||
[RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
|
||||
RFC1034, November 1987.
|
||||
|
||||
[RFC1035] Mockapetris, P.V., "Domain names - Implementation and
|
||||
Specification", RFC1035, November 1987.
|
||||
|
||||
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
|
||||
Application and Support", RFC1123, October 1989.
|
||||
|
||||
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
|
||||
Changes (DNS NOTIFY)", RFC1996, August 1996.
|
||||
|
||||
[RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
|
||||
RFC2181, July 1997.
|
||||
|
||||
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
|
||||
RFC2308, March 1998.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
|
||||
August 1999.
|
||||
|
||||
[RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
|
||||
and Issues with IPV6 DNS", April 2006.
|
||||
|
||||
10 - Authors' Addresses
|
||||
|
||||
Paul Vixie
|
||||
Internet Systems Consortium, Inc.
|
||||
950 Charter Street
|
||||
Redwood City, CA 94063
|
||||
+1 650 423 1301
|
||||
vixie@isc.org
|
||||
|
||||
Akira Kato
|
||||
University of Tokyo, Information Technology Center
|
||||
2-11-16 Yayoi Bunkyo
|
||||
Tokyo 113-8658, JAPAN
|
||||
+81 3 5841 2750
|
||||
kato@wide.ad.jp
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 11]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
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).
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 12]
|
||||
|
||||
|
||||
@@ -20,7 +20,6 @@
|
||||
1750: Randomness Recommendations for Security
|
||||
1876: A Means for Expressing Location Information in the Domain Name System
|
||||
1886: DNS Extensions to support IP version 6
|
||||
1912: Common DNS Operational and Configuration Errors
|
||||
1982: Serial Number Arithmetic
|
||||
1995: Incremental Zone Transfer in DNS
|
||||
1996: A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
|
||||
@@ -120,9 +119,6 @@
|
||||
4701: A DNS Resource Record (RR) for Encoding
|
||||
Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
|
||||
4892: Requirements for a Mechanism Identifying a Name Server Instance
|
||||
5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors
|
||||
5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
|
||||
5205: Host Identity Protocol (HIP) Domain Name System (DNS) Extension
|
||||
5295: Host Identity Protocol (HIP) Domain Name System (DNS) Extension
|
||||
5507: Design Choices When Expanding the DNS
|
||||
5702: Use of SHA-2 Algorithms with RSA in
|
||||
DNSKEY and RRSIG Resource Records for DNSSEC
|
||||
|
||||
@@ -1,899 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group D. Barr
|
||||
Request for Comments: 1912 The Pennsylvania State University
|
||||
Obsoletes: 1537 February 1996
|
||||
Category: Informational
|
||||
|
||||
|
||||
Common DNS Operational and Configuration Errors
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This memo provides information for the Internet community. This memo
|
||||
does not specify an Internet standard of any kind. Distribution of
|
||||
this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
This memo describes errors often found in both the operation of
|
||||
Domain Name System (DNS) servers, and in the data that these DNS
|
||||
servers contain. This memo tries to summarize current Internet
|
||||
requirements as well as common practice in the operation and
|
||||
configuration of the DNS. This memo also tries to summarize or
|
||||
expand upon issues raised in [RFC 1537].
|
||||
|
||||
1. Introduction
|
||||
|
||||
Running a nameserver is not a trivial task. There are many things
|
||||
that can go wrong, and many decisions have to be made about what data
|
||||
to put in the DNS and how to set up servers. This memo attempts to
|
||||
address many of the common mistakes and pitfalls that are made in DNS
|
||||
data as well as in the operation of nameservers. Discussions are
|
||||
also made regarding some other relevant issues such as server or
|
||||
resolver bugs, and a few political issues with respect to the
|
||||
operation of DNS on the Internet.
|
||||
|
||||
2. DNS Data
|
||||
|
||||
This section discusses problems people typically have with the DNS
|
||||
data in their nameserver, as found in the zone data files that the
|
||||
nameserver loads into memory.
|
||||
|
||||
2.1 Inconsistent, Missing, or Bad Data
|
||||
|
||||
Every Internet-reachable host should have a name. The consequences
|
||||
of this are becoming more and more obvious. Many services available
|
||||
on the Internet will not talk to you if you aren't correctly
|
||||
registered in the DNS.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 1]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
Make sure your PTR and A records match. For every IP address, there
|
||||
should be a matching PTR record in the in-addr.arpa domain. If a
|
||||
host is multi-homed, (more than one IP address) make sure that all IP
|
||||
addresses have a corresponding PTR record (not just the first one).
|
||||
Failure to have matching PTR and A records can cause loss of Internet
|
||||
services similar to not being registered in the DNS at all. Also,
|
||||
PTR records must point back to a valid A record, not a alias defined
|
||||
by a CNAME. It is highly recommended that you use some software
|
||||
which automates this checking, or generate your DNS data from a
|
||||
database which automatically creates consistent data.
|
||||
|
||||
DNS domain names consist of "labels" separated by single dots. The
|
||||
DNS is very liberal in its rules for the allowable characters in a
|
||||
domain name. However, if a domain name is used to name a host, it
|
||||
should follow rules restricting host names. Further if a name is
|
||||
used for mail, it must follow the naming rules for names in mail
|
||||
addresses.
|
||||
|
||||
Allowable characters in a label for a host name are only ASCII
|
||||
letters, digits, and the `-' character. Labels may not be all
|
||||
numbers, but may have a leading digit (e.g., 3com.com). Labels must
|
||||
end and begin only with a letter or digit. See [RFC 1035] and [RFC
|
||||
1123]. (Labels were initially restricted in [RFC 1035] to start with
|
||||
a letter, and some older hosts still reportedly have problems with
|
||||
the relaxation in [RFC 1123].) Note there are some Internet
|
||||
hostnames which violate this rule (411.org, 1776.com). The presence
|
||||
of underscores in a label is allowed in [RFC 1033], except [RFC 1033]
|
||||
is informational only and was not defining a standard. There is at
|
||||
least one popular TCP/IP implementation which currently refuses to
|
||||
talk to hosts named with underscores in them. It must be noted that
|
||||
the language in [1035] is such that these rules are voluntary -- they
|
||||
are there for those who wish to minimize problems. Note that the
|
||||
rules for Internet host names also apply to hosts and addresses used
|
||||
in SMTP (See RFC 821).
|
||||
|
||||
If a domain name is to be used for mail (not involving SMTP), it must
|
||||
follow the rules for mail in [RFC 822], which is actually more
|
||||
liberal than the above rules. Labels for mail can be any ASCII
|
||||
character except "specials", control characters, and whitespace
|
||||
characters. "Specials" are specific symbols used in the parsing of
|
||||
addresses. They are the characters "()<>@,;:\".[]". (The "!"
|
||||
character wasn't in [RFC 822], however it also shouldn't be used due
|
||||
to the conflict with UUCP mail as defined in RFC 976) However, since
|
||||
today almost all names which are used for mail on the Internet are
|
||||
also names used for hostnames, one rarely sees addresses using these
|
||||
relaxed standard, but mail software should be made liberal and robust
|
||||
enough to accept them.
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 2]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
You should also be careful to not have addresses which are valid
|
||||
alternate syntaxes to the inet_ntoa() library call. For example 0xe
|
||||
is a valid name, but if you were to type "telnet 0xe", it would try
|
||||
to connect to IP address 0.0.0.14. It is also rumored that there
|
||||
exists some broken inet_ntoa() routines that treat an address like
|
||||
x400 as an IP address.
|
||||
|
||||
Certain operating systems have limitations on the length of their own
|
||||
hostname. While not strictly of issue to the DNS, you should be
|
||||
aware of your operating system's length limits before choosing the
|
||||
name of a host.
|
||||
|
||||
Remember that many resource records (abbreviated RR) take on more
|
||||
than one argument. HINFO requires two arguments, as does RP. If you
|
||||
don't supply enough arguments, servers sometime return garbage for
|
||||
the missing fields. If you need to include whitespace within any
|
||||
data, you must put the string in quotes.
|
||||
|
||||
2.2 SOA records
|
||||
|
||||
In the SOA record of every zone, remember to fill in the e-mail
|
||||
address that will get to the person who maintains the DNS at your
|
||||
site (commonly referred to as "hostmaster"). The `@' in the e-mail
|
||||
must be replaced by a `.' first. Do not try to put an `@' sign in
|
||||
this address. If the local part of the address already contains a
|
||||
`.' (e.g., John.Smith@widget.xx), then you need to quote the `.' by
|
||||
preceding it with `\' character. (e.g., to become
|
||||
John\.Smith.widget.xx) Alternately (and preferred), you can just use
|
||||
the generic name `hostmaster', and use a mail alias to redirect it to
|
||||
the appropriate persons. There exists software which uses this field
|
||||
to automatically generate the e-mail address for the zone contact.
|
||||
This software will break if this field is improperly formatted. It
|
||||
is imperative that this address get to one or more real persons,
|
||||
because it is often used for everything from reporting bad DNS data
|
||||
to reporting security incidents.
|
||||
|
||||
Even though some BIND versions allow you to use a decimal in a serial
|
||||
number, don't. A decimal serial number is converted to an unsigned
|
||||
32-bit integer internally anyway. The formula for a n.m serial
|
||||
number is n*10^(3+int(0.9+log10(m))) + m which translates to
|
||||
something rather unexpected. For example it's routinely possible
|
||||
with a decimal serial number (perhaps automatically generated by
|
||||
SCCS) to be incremented such that it is numerically larger, but after
|
||||
the above conversion yield a serial number which is LOWER than
|
||||
before. Decimal serial numbers have been officially deprecated in
|
||||
recent BIND versions. The recommended syntax is YYYYMMDDnn
|
||||
(YYYY=year, MM=month, DD=day, nn=revision number. This won't
|
||||
overflow until the year 4294.
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 3]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
Choose logical values for the timer values in the SOA record (note
|
||||
values below must be expressed as seconds in the zone data):
|
||||
|
||||
Refresh: How often a secondary will poll the primary server to see
|
||||
if the serial number for the zone has increased (so it knows
|
||||
to request a new copy of the data for the zone). Set this to
|
||||
how long your secondaries can comfortably contain out-of-date
|
||||
data. You can keep it short (20 mins to 2 hours) if you
|
||||
aren't worried about a small increase in bandwidth used, or
|
||||
longer (2-12 hours) if your Internet connection is slow or is
|
||||
started on demand. Recent BIND versions (4.9.3) have optional
|
||||
code to automatically notify secondaries that data has
|
||||
changed, allowing you to set this TTL to a long value (one
|
||||
day, or more).
|
||||
|
||||
Retry: If a secondary was unable to contact the primary at the
|
||||
last refresh, wait the retry value before trying again. This
|
||||
value isn't as important as others, unless the secondary is on
|
||||
a distant network from the primary or the primary is more
|
||||
prone to outages. It's typically some fraction of the refresh
|
||||
interval.
|
||||
|
||||
|
||||
Expire: How long a secondary will still treat its copy of the zone
|
||||
data as valid if it can't contact the primary. This value
|
||||
should be greater than how long a major outage would typically
|
||||
last, and must be greater than the minimum and retry
|
||||
intervals, to avoid having a secondary expire the data before
|
||||
it gets a chance to get a new copy. After a zone is expired a
|
||||
secondary will still continue to try to contact the primary,
|
||||
but it will no longer provide nameservice for the zone. 2-4
|
||||
weeks are suggested values.
|
||||
|
||||
Minimum: The default TTL (time-to-live) for resource records --
|
||||
how long data will remain in other nameservers' cache. ([RFC
|
||||
1035] defines this to be the minimum value, but servers seem
|
||||
to always implement this as the default value) This is by far
|
||||
the most important timer. Set this as large as is comfortable
|
||||
given how often you update your nameserver. If you plan to
|
||||
make major changes, it's a good idea to turn this value down
|
||||
temporarily beforehand. Then wait the previous minimum value,
|
||||
make your changes, verify their correctness, and turn this
|
||||
value back up. 1-5 days are typical values. Remember this
|
||||
value can be overridden on individual resource records.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 4]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
As you can see, the typical values above for the timers vary widely.
|
||||
Popular documentation like [RFC 1033] recommended a day for the
|
||||
minimum TTL, which is now considered too low except for zones with
|
||||
data that vary regularly. Once a DNS stabilizes, values on the order
|
||||
of 3 or more days are recommended. It is also recommended that you
|
||||
individually override the TTL on certain RRs which are often
|
||||
referenced and don't often change to have very large values (1-2
|
||||
weeks). Good examples of this are the MX, A, and PTR records of your
|
||||
mail host(s), the NS records of your zone, and the A records of your
|
||||
nameservers.
|
||||
|
||||
2.3 Glue A Records
|
||||
|
||||
Glue records are A records that are associated with NS records to
|
||||
provide "bootstrapping" information to the nameserver. For example:
|
||||
|
||||
podunk.xx. in ns ns1.podunk.xx.
|
||||
in ns ns2.podunk.xx.
|
||||
ns1.podunk.xx. in a 1.2.3.4
|
||||
ns2.podunk.xx. in a 1.2.3.5
|
||||
|
||||
Here, the A records are referred to as "Glue records".
|
||||
|
||||
Glue records are required only in forward zone files for nameservers
|
||||
that are located in the subdomain of the current zone that is being
|
||||
delegated. You shouldn't have any A records in an in-addr.arpa zone
|
||||
file (unless you're using RFC 1101-style encoding of subnet masks).
|
||||
|
||||
If your nameserver is multi-homed (has more than one IP address), you
|
||||
must list all of its addresses in the glue to avoid cache
|
||||
inconsistency due to differing TTL values, causing some lookups to
|
||||
not find all addresses for your nameserver.
|
||||
|
||||
Some people get in the bad habit of putting in a glue record whenever
|
||||
they add an NS record "just to make sure". Having duplicate glue
|
||||
records in your zone files just makes it harder when a nameserver
|
||||
moves to a new IP address, or is removed. You'll spend hours trying
|
||||
to figure out why random people still see the old IP address for some
|
||||
host, because someone forgot to change or remove a glue record in
|
||||
some other file. Newer BIND versions will ignore these extra glue
|
||||
records in local zone files.
|
||||
|
||||
Older BIND versions (4.8.3 and previous) have a problem where it
|
||||
inserts these extra glue records in the zone transfer data to
|
||||
secondaries. If one of these glues is wrong, the error can be
|
||||
propagated to other nameservers. If two nameservers are secondaries
|
||||
for other zones of each other, it's possible for one to continually
|
||||
pass old glue records back to the other. The only way to get rid of
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 5]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
the old data is to kill both of them, remove the saved backup files,
|
||||
and restart them. Combined with that those same versions also tend
|
||||
to become infected more easily with bogus data found in other non-
|
||||
secondary nameservers (like the root zone data).
|
||||
|
||||
2.4 CNAME records
|
||||
|
||||
A CNAME record is not allowed to coexist with any other data. In
|
||||
other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you
|
||||
can't also have an MX record for suzy.podunk.edu, or an A record, or
|
||||
even a TXT record. Especially do not try to combine CNAMEs and NS
|
||||
records like this!:
|
||||
|
||||
|
||||
podunk.xx. IN NS ns1
|
||||
IN NS ns2
|
||||
IN CNAME mary
|
||||
mary IN A 1.2.3.4
|
||||
|
||||
|
||||
This is often attempted by inexperienced administrators as an obvious
|
||||
way to allow your domain name to also be a host. However, DNS
|
||||
servers like BIND will see the CNAME and refuse to add any other
|
||||
resources for that name. Since no other records are allowed to
|
||||
coexist with a CNAME, the NS entries are ignored. Therefore all the
|
||||
hosts in the podunk.xx domain are ignored as well!
|
||||
|
||||
If you want to have your domain also be a host, do the following:
|
||||
|
||||
podunk.xx. IN NS ns1
|
||||
IN NS ns2
|
||||
IN A 1.2.3.4
|
||||
mary IN A 1.2.3.4
|
||||
|
||||
Don't go overboard with CNAMEs. Use them when renaming hosts, but
|
||||
plan to get rid of them (and inform your users). However CNAMEs are
|
||||
useful (and encouraged) for generalized names for servers -- `ftp'
|
||||
for your ftp server, `www' for your Web server, `gopher' for your
|
||||
Gopher server, `news' for your Usenet news server, etc.
|
||||
|
||||
Don't forget to delete the CNAMEs associated with a host if you
|
||||
delete the host it is an alias for. Such "stale CNAMEs" are a waste
|
||||
of resources.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 6]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
Don't use CNAMEs in combination with RRs which point to other names
|
||||
like MX, CNAME, PTR and NS. (PTR is an exception if you want to
|
||||
implement classless in-addr delegation.) For example, this is
|
||||
strongly discouraged:
|
||||
|
||||
podunk.xx. IN MX mailhost
|
||||
mailhost IN CNAME mary
|
||||
mary IN A 1.2.3.4
|
||||
|
||||
|
||||
[RFC 1034] in section 3.6.2 says this should not be done, and [RFC
|
||||
974] explicitly states that MX records shall not point to an alias
|
||||
defined by a CNAME. This results in unnecessary indirection in
|
||||
accessing the data, and DNS resolvers and servers need to work more
|
||||
to get the answer. If you really want to do this, you can accomplish
|
||||
the same thing by using a preprocessor such as m4 on your host files.
|
||||
|
||||
Also, having chained records such as CNAMEs pointing to CNAMEs may
|
||||
make administration issues easier, but is known to tickle bugs in
|
||||
some resolvers that fail to check loops correctly. As a result some
|
||||
hosts may not be able to resolve such names.
|
||||
|
||||
Having NS records pointing to a CNAME is bad and may conflict badly
|
||||
with current BIND servers. In fact, current BIND implementations
|
||||
will ignore such records, possibly leading to a lame delegation.
|
||||
There is a certain amount of security checking done in BIND to
|
||||
prevent spoofing DNS NS records. Also, older BIND servers reportedly
|
||||
will get caught in an infinite query loop trying to figure out the
|
||||
address for the aliased nameserver, causing a continuous stream of
|
||||
DNS requests to be sent.
|
||||
|
||||
2.5 MX records
|
||||
|
||||
It is a good idea to give every host an MX record, even if it points
|
||||
to itself! Some mailers will cache MX records, but will always need
|
||||
to check for an MX before sending mail. If a site does not have an
|
||||
MX, then every piece of mail may result in one more resolver query,
|
||||
since the answer to the MX query often also contains the IP addresses
|
||||
of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to
|
||||
support the MX mechanism.
|
||||
|
||||
Put MX records even on hosts that aren't intended to send or receive
|
||||
e-mail. If there is a security problem involving one of these hosts,
|
||||
some people will mistakenly send mail to postmaster or root at the
|
||||
site without checking first to see if it is a "real" host or just a
|
||||
terminal or personal computer that's not set up to accept e-mail. If
|
||||
you give it an MX record, then the e-mail can be redirected to a real
|
||||
person. Otherwise mail can just sit in a queue for hours or days
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 7]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
until the mailer gives up trying to send it.
|
||||
|
||||
Don't forget that whenever you add an MX record, you need to inform
|
||||
the target mailer if it is to treat the first host as "local". (The
|
||||
"Cw" flag in sendmail, for example)
|
||||
|
||||
If you add an MX record which points to an external host (e.g., for
|
||||
the purposes of backup mail routing) be sure to ask permission from
|
||||
that site first. Otherwise that site could get rather upset and take
|
||||
action (like throw your mail away, or appeal to higher authorities
|
||||
like your parent DNS administrator or network provider.)
|
||||
|
||||
2.6 Other Resource Records
|
||||
|
||||
2.6.1 WKS
|
||||
|
||||
WKS records are deprecated in [RFC 1123]. They serve no known useful
|
||||
function, except internally among LISP machines. Don't use them.
|
||||
|
||||
2.6.2 HINFO
|
||||
|
||||
On the issue HINFO records, some will argue that these is a security
|
||||
problem (by broadcasting what vendor hardware and operating system
|
||||
you so people can run systematic attacks on known vendor security
|
||||
holes). If you do use them, you should keep up to date with known
|
||||
vendor security problems. However, they serve a useful purpose.
|
||||
Don't forget that HINFO requires two arguments, the hardware type,
|
||||
and the operating system.
|
||||
|
||||
HINFO is sometimes abused to provide other information. The record
|
||||
is meant to provide specific information about the machine itself.
|
||||
If you need to express other information about the host in the DNS,
|
||||
use TXT.
|
||||
|
||||
2.6.3 TXT
|
||||
|
||||
TXT records have no specific definition. You can put most anything
|
||||
in them. Some use it for a generic description of the host, some put
|
||||
specific information like its location, primary user, or maybe even a
|
||||
phone number.
|
||||
|
||||
2.6.4 RP
|
||||
|
||||
RP records are relatively new. They are used to specify an e-mail
|
||||
address (see first paragraph of section 2.2) of the "Responsible
|
||||
Person" of the host, and the name of a TXT record where you can get
|
||||
more information. See [RFC 1183].
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 8]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
2.7 Wildcard records
|
||||
|
||||
Wildcard MXs are useful mostly for non IP-connected sites. A common
|
||||
mistake is thinking that a wildcard MX for a zone will apply to all
|
||||
hosts in the zone. A wildcard MX will apply only to names in the
|
||||
zone which aren't listed in the DNS at all. e.g.,
|
||||
|
||||
podunk.xx. IN NS ns1
|
||||
IN NS ns2
|
||||
mary IN A 1.2.3.4
|
||||
*.podunk.xx. IN MX 5 sue
|
||||
|
||||
Mail for mary.podunk.xx will be sent to itself for delivery. Only
|
||||
mail for jane.podunk.xx or any hosts you don't see above will be sent
|
||||
to the MX. For most Internet sites, wildcard MX records are not
|
||||
useful. You need to put explicit MX records on every host.
|
||||
|
||||
Wildcard MXs can be bad, because they make some operations succeed
|
||||
when they should fail instead. Consider the case where someone in
|
||||
the domain "widget.com" tries to send mail to "joe@larry". If the
|
||||
host "larry" doesn't actually exist, the mail should in fact bounce
|
||||
immediately. But because of domain searching the address gets
|
||||
resolved to "larry.widget.com", and because of the wildcard MX this
|
||||
is a valid address according to DNS. Or perhaps someone simply made
|
||||
a typo in the hostname portion of the address. The mail message then
|
||||
gets routed to the mail host, which then rejects the mail with
|
||||
strange error messages like "I refuse to talk to myself" or "Local
|
||||
configuration error".
|
||||
|
||||
Wildcard MX records are good for when you have a large number of
|
||||
hosts which are not directly Internet-connected (for example, behind
|
||||
a firewall) and for administrative or political reasons it is too
|
||||
difficult to have individual MX records for every host, or to force
|
||||
all e-mail addresses to be "hidden" behind one or more domain names.
|
||||
In that case, you must divide your DNS into two parts, an internal
|
||||
DNS, and an external DNS. The external DNS will have only a few
|
||||
hosts and explicit MX records, and one or more wildcard MXs for each
|
||||
internal domain. Internally the DNS will be complete, with all
|
||||
explicit MX records and no wildcards.
|
||||
|
||||
Wildcard As and CNAMEs are possible too, and are really confusing to
|
||||
users, and a potential nightmare if used without thinking first. It
|
||||
could result (due again to domain searching) in any telnet/ftp
|
||||
attempts from within the domain to unknown hosts to be directed to
|
||||
one address. One such wildcard CNAME (in *.edu.com) caused
|
||||
Internet-wide loss of services and potential security nightmares due
|
||||
to unexpected interactions with domain searching. It resulted in
|
||||
swift fixes, and even an RFC ([RFC 1535]) documenting the problem.
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 9]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
2.8 Authority and Delegation Errors (NS records)
|
||||
|
||||
You are required to have at least two nameservers for every domain,
|
||||
though more is preferred. Have secondaries outside your network. If
|
||||
the secondary isn't under your control, periodically check up on them
|
||||
and make sure they're getting current zone data from you. Queries to
|
||||
their nameserver about your hosts should always result in an
|
||||
"authoritative" response. If not, this is called a "lame
|
||||
delegation". A lame delegations exists when a nameserver is
|
||||
delegated responsibility for providing nameservice for a zone (via NS
|
||||
records) but is not performing nameservice for that zone (usually
|
||||
because it is not set up as a primary or secondary for the zone).
|
||||
|
||||
The "classic" lame delegation can be illustrated in this example:
|
||||
|
||||
podunk.xx. IN NS ns1.podunk.xx.
|
||||
IN NS ns0.widget.com.
|
||||
|
||||
"podunk.xx" is a new domain which has recently been created, and
|
||||
"ns1.podunk.xx" has been set up to perform nameservice for the zone.
|
||||
They haven't quite finished everything yet and haven't made sure that
|
||||
the hostmaster at "ns0.widget.com" has set up to be a proper
|
||||
secondary, and thus has no information about the podunk.xx domain,
|
||||
even though the DNS says it is supposed to. Various things can
|
||||
happen depending on which nameserver is used. At best, extra DNS
|
||||
traffic will result from a lame delegation. At worst, you can get
|
||||
unresolved hosts and bounced e-mail.
|
||||
|
||||
Also, sometimes a nameserver is moved to another host or removed from
|
||||
the list of secondaries. Unfortunately due to caching of NS records,
|
||||
many sites will still think that a host is a secondary after that
|
||||
host has stopped providing nameservice. In order to prevent lame
|
||||
delegations while the cache is being aged, continue to provide
|
||||
nameservice on the old nameserver for the length of the maximum of
|
||||
the minimum plus refresh times for the zone and the parent zone.
|
||||
(See section 2.2)
|
||||
|
||||
Whenever a primary or secondary is removed or changed, it takes a
|
||||
fair amount of human coordination among the parties involved. (The
|
||||
site itself, it's parent, and the site hosting the secondary) When a
|
||||
primary moves, make sure all secondaries have their named.boot files
|
||||
updated and their servers reloaded. When a secondary moves, make
|
||||
sure the address records at both the primary and parent level are
|
||||
changed.
|
||||
|
||||
It's also been reported that some distant sites like to pick popular
|
||||
nameservers like "ns.uu.net" and just add it to their list of NS
|
||||
records in hopes that they will magically perform additional
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 10]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
nameservice for them. This is an even worse form of lame delegation,
|
||||
since this adds traffic to an already busy nameserver. Please
|
||||
contact the hostmasters of sites which have lame delegations.
|
||||
Various tools can be used to detect or actively find lame
|
||||
delegations. See the list of contributed software in the BIND
|
||||
distribution.
|
||||
|
||||
Make sure your parent domain has the same NS records for your zone as
|
||||
you do. (Don't forget your in-addr.arpa zones too!). Do not list
|
||||
too many (7 is the recommended maximum), as this just makes things
|
||||
harder to manage and is only really necessary for very popular top-
|
||||
level or root zones. You also run the risk of overflowing the 512-
|
||||
byte limit of a UDP packet in the response to an NS query. If this
|
||||
happens, resolvers will "fall back" to using TCP requests, resulting
|
||||
in increased load on your nameserver.
|
||||
|
||||
It's important when picking geographic locations for secondary
|
||||
nameservers to minimize latency as well as increase reliability.
|
||||
Keep in mind network topologies. For example if your site is on the
|
||||
other end of a slow local or international link, consider a secondary
|
||||
on the other side of the link to decrease average latency. Contact
|
||||
your Internet service provider or parent domain contact for more
|
||||
information about secondaries which may be available to you.
|
||||
|
||||
3. BIND operation
|
||||
|
||||
This section discusses common problems people have in the actual
|
||||
operation of the nameserver (specifically, BIND). Not only must the
|
||||
data be correct as explained above, but the nameserver must be
|
||||
operated correctly for the data to be made available.
|
||||
|
||||
3.1 Serial numbers
|
||||
|
||||
Each zone has a serial number associated with it. Its use is for
|
||||
keeping track of who has the most current data. If and only if the
|
||||
primary's serial number of the zone is greater will the secondary ask
|
||||
the primary for a copy of the new zone data (see special case below).
|
||||
|
||||
Don't forget to change the serial number when you change data! If
|
||||
you don't, your secondaries will not transfer the new zone
|
||||
information. Automating the incrementing of the serial number with
|
||||
software is also a good idea.
|
||||
|
||||
If you make a mistake and increment the serial number too high, and
|
||||
you want to reset the serial number to a lower value, use the
|
||||
following procedure:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 11]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
Take the `incorrect' serial number and add 2147483647 to it. If
|
||||
the number exceeds 4294967296, subtract 4294967296. Load the
|
||||
resulting number. Then wait 2 refresh periods to allow the zone
|
||||
to propagate to all servers.
|
||||
|
||||
Repeat above until the resulting serial number is less than the
|
||||
target serial number.
|
||||
|
||||
Up the serial number to the target serial number.
|
||||
|
||||
This procedure won't work if one of your secondaries is running an
|
||||
old version of BIND (4.8.3 or earlier). In this case you'll have to
|
||||
contact the hostmaster for that secondary and have them kill the
|
||||
secondary servers, remove the saved backup file, and restart the
|
||||
server. Be careful when editing the serial number -- DNS admins
|
||||
don't like to kill and restart nameservers because you lose all that
|
||||
cached data.
|
||||
|
||||
3.2 Zone file style guide
|
||||
|
||||
Here are some useful tips in structuring your zone files. Following
|
||||
these will help you spot mistakes, and avoid making more.
|
||||
|
||||
Be consistent with the style of entries in your DNS files. If your
|
||||
$ORIGIN is podunk.xx., try not to write entries like:
|
||||
|
||||
mary IN A 1.2.3.1
|
||||
sue.podunk.xx. IN A 1.2.3.2
|
||||
|
||||
or:
|
||||
|
||||
bobbi IN A 1.2.3.2
|
||||
IN MX mary.podunk.xx.
|
||||
|
||||
|
||||
Either use all FQDNs (Fully Qualified Domain Names) everywhere or
|
||||
used unqualified names everywhere. Or have FQDNs all on the right-
|
||||
hand side but unqualified names on the left. Above all, be
|
||||
consistent.
|
||||
|
||||
Use tabs between fields, and try to keep columns lined up. It makes
|
||||
it easier to spot missing fields (note some fields such as "IN" are
|
||||
inherited from the previous record and may be left out in certain
|
||||
circumstances.)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 12]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
Remember you don't need to repeat the name of the host when you are
|
||||
defining multiple records for one host. Be sure also to keep all
|
||||
records associated with a host together in the file. It will make
|
||||
things more straightforward when it comes time to remove or rename a
|
||||
host.
|
||||
|
||||
Always remember your $ORIGIN. If you don't put a `.' at the end of
|
||||
an FQDN, it's not recognized as an FQDN. If it is not an FQDN, then
|
||||
the nameserver will append $ORIGIN to the name. Double check, triple
|
||||
check, those trailing dots, especially in in-addr.arpa zone files,
|
||||
where they are needed the most.
|
||||
|
||||
Be careful with the syntax of the SOA and WKS records (the records
|
||||
which use parentheses). BIND is not very flexible in how it parses
|
||||
these records. See the documentation for BIND.
|
||||
|
||||
3.3 Verifying data
|
||||
|
||||
Verify the data you just entered or changed by querying the resolver
|
||||
with dig (or your favorite DNS tool, many are included in the BIND
|
||||
distribution) after a change. A few seconds spent double checking
|
||||
can save hours of trouble, lost mail, and general headaches. Also be
|
||||
sure to check syslog output when you reload the nameserver. If you
|
||||
have grievous errors in your DNS data or boot file, named will report
|
||||
it via syslog.
|
||||
|
||||
It is also highly recommended that you automate this checking, either
|
||||
with software which runs sanity checks on the data files before they
|
||||
are loaded into the nameserver, or with software which checks the
|
||||
data already loaded in the nameserver. Some contributed software to
|
||||
do this is included in the BIND distribution.
|
||||
|
||||
4. Miscellaneous Topics
|
||||
|
||||
4.1 Boot file setup
|
||||
|
||||
Certain zones should always be present in nameserver configurations:
|
||||
|
||||
primary localhost localhost
|
||||
primary 0.0.127.in-addr.arpa 127.0
|
||||
primary 255.in-addr.arpa 255
|
||||
primary 0.in-addr.arpa 0
|
||||
|
||||
These are set up to either provide nameservice for "special"
|
||||
addresses, or to help eliminate accidental queries for broadcast or
|
||||
local address to be sent off to the root nameservers. All of these
|
||||
files will contain NS and SOA records just like the other zone files
|
||||
you maintain, the exception being that you can probably make the SOA
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 13]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
timers very long, since this data will never change.
|
||||
|
||||
The "localhost" address is a "special" address which always refers to
|
||||
the local host. It should contain the following line:
|
||||
|
||||
localhost. IN A 127.0.0.1
|
||||
|
||||
The "127.0" file should contain the line:
|
||||
|
||||
1 PTR localhost.
|
||||
|
||||
There has been some extensive discussion about whether or not to
|
||||
append the local domain to it. The conclusion is that "localhost."
|
||||
would be the best solution. The reasons given include:
|
||||
|
||||
"localhost" by itself is used and expected to work in some
|
||||
systems.
|
||||
|
||||
Translating 127.0.0.1 into "localhost.dom.ain" can cause some
|
||||
software to connect back to the loopback interface when it didn't
|
||||
want to because "localhost" is not equal to "localhost.dom.ain".
|
||||
|
||||
The "255" and "0" files should not contain any additional data beyond
|
||||
the NS and SOA records.
|
||||
|
||||
Note that future BIND versions may include all or some of this data
|
||||
automatically without additional configuration.
|
||||
|
||||
4.2 Other Resolver and Server bugs
|
||||
|
||||
Very old versions of the DNS resolver have a bug that cause queries
|
||||
for names that look like IP addresses to go out, because the user
|
||||
supplied an IP address and the software didn't realize that it didn't
|
||||
need to be resolved. This has been fixed but occasionally it still
|
||||
pops up. It's important because this bug means that these queries
|
||||
will be sent directly to the root nameservers, adding to an already
|
||||
heavy DNS load.
|
||||
|
||||
While running a secondary nameserver off another secondary nameserver
|
||||
is possible, it is not recommended unless necessary due to network
|
||||
topologies. There are known cases where it has led to problems like
|
||||
bogus TTL values. While this may be caused by older or flawed DNS
|
||||
implementations, you should not chain secondaries off of one another
|
||||
since this builds up additional reliability dependencies as well as
|
||||
adds additional delays in updates of new zone data.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 14]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
4.3 Server issues
|
||||
|
||||
DNS operates primarily via UDP (User Datagram Protocol) messages.
|
||||
Some UNIX operating systems, in an effort to save CPU cycles, run
|
||||
with UDP checksums turned off. The relative merits of this have long
|
||||
been debated. However, with the increase in CPU speeds, the
|
||||
performance considerations become less and less important. It is
|
||||
strongly encouraged that you turn on UDP checksumming to avoid
|
||||
corrupted data not only with DNS but with other services that use UDP
|
||||
(like NFS). Check with your operating system documentation to verify
|
||||
that UDP checksumming is enabled.
|
||||
|
||||
References
|
||||
|
||||
[RFC 974] Partridge, C., "Mail routing and the domain system", STD
|
||||
14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
|
||||
|
||||
[RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC
|
||||
1033, USC/Information Sciences Institute, November 1987.
|
||||
|
||||
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
|
||||
STD 13, RFC 1034, USC/Information Sciences Institute,
|
||||
November 1987.
|
||||
|
||||
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and
|
||||
Specification", STD 13, RFC 1035, USC/Information Sciences
|
||||
Institute, November 1987.
|
||||
|
||||
[RFC 1123] Braden, R., "Requirements for Internet Hosts --
|
||||
Application and Support", STD 3, RFC 1123, IETF, October
|
||||
1989.
|
||||
|
||||
[RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC
|
||||
1178, Integrated Systems Group/NIST, August 1990.
|
||||
|
||||
[RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart,
|
||||
"New DNS RR Definitions", RFC 1183, October 1990.
|
||||
|
||||
[RFC 1535] Gavron, E., "A Security Problem and Proposed Correction
|
||||
With Widely Deployed DNS Software", RFC 1535, ACES
|
||||
Research Inc., October 1993.
|
||||
|
||||
[RFC 1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
|
||||
Miller, "Common DNS Implementation Errors and Suggested
|
||||
Fixes", RFC 1536, USC/Information Sciences Institute, USC,
|
||||
October 1993.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 15]
|
||||
|
||||
RFC 1912 Common DNS Errors February 1996
|
||||
|
||||
|
||||
[RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors",
|
||||
RFC 1537, CWI, October 1993.
|
||||
|
||||
[RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN,
|
||||
November 1994.
|
||||
|
||||
[BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND",
|
||||
Vixie Enterprises, July 1994.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Security issues are not discussed in this memo.
|
||||
|
||||
6. Author's Address
|
||||
|
||||
David Barr
|
||||
The Pennsylvania State University
|
||||
Department of Mathematics
|
||||
334 Whitmore Building
|
||||
University Park, PA 16802
|
||||
|
||||
Voice: +1 814 863 7374
|
||||
Fax: +1 814 863-8311
|
||||
EMail: barr@math.psu.edu
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Barr Informational [Page 16]
|
||||
|
||||
@@ -1,787 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group M. StJohns
|
||||
Request for Comments: 5011 Independent
|
||||
Category: Standards Track September 2007
|
||||
|
||||
|
||||
Automated Updates of DNS Security (DNSSEC) Trust Anchors
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes a means for automated, authenticated, and
|
||||
authorized updating of DNSSEC "trust anchors". The method provides
|
||||
protection against N-1 key compromises of N keys in the trust point
|
||||
key set. Based on the trust established by the presence of a current
|
||||
anchor, other anchors may be added at the same place in the
|
||||
hierarchy, and, ultimately, supplant the existing anchor(s).
|
||||
|
||||
This mechanism will require changes to resolver management behavior
|
||||
(but not resolver resolution behavior), and the addition of a single
|
||||
flag bit to the DNSKEY record.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 1]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
1.1. Compliance Nomenclature ....................................3
|
||||
2. Theory of Operation .............................................3
|
||||
2.1. Revocation .................................................4
|
||||
2.2. Add Hold-Down ..............................................4
|
||||
2.3. Active Refresh .............................................5
|
||||
2.4. Resolver Parameters ........................................6
|
||||
2.4.1. Add Hold-Down Time ..................................6
|
||||
2.4.2. Remove Hold-Down Time ...............................6
|
||||
2.4.3. Minimum Trust Anchors per Trust Point ...............6
|
||||
3. Changes to DNSKEY RDATA Wire Format .............................6
|
||||
4. State Table .....................................................6
|
||||
4.1. Events .....................................................7
|
||||
4.2. States .....................................................7
|
||||
5. Trust Point Deletion ............................................8
|
||||
6. Scenarios - Informative .........................................9
|
||||
6.1. Adding a Trust Anchor ......................................9
|
||||
6.2. Deleting a Trust Anchor ....................................9
|
||||
6.3. Key Roll-Over .............................................10
|
||||
6.4. Active Key Compromised ....................................10
|
||||
6.5. Stand-by Key Compromised ..................................10
|
||||
6.6. Trust Point Deletion ......................................10
|
||||
7. IANA Considerations ............................................11
|
||||
8. Security Considerations ........................................11
|
||||
8.1. Key Ownership vs. Acceptance Policy .......................11
|
||||
8.2. Multiple Key Compromise ...................................12
|
||||
8.3. Dynamic Updates ...........................................12
|
||||
9. Normative References ...........................................12
|
||||
10. Informative References ........................................12
|
||||
|
||||
1. Introduction
|
||||
|
||||
As part of the reality of fielding DNSSEC (Domain Name System
|
||||
Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
|
||||
come to the realization that there will not be one signed name space,
|
||||
but rather islands of signed name spaces each originating from
|
||||
specific points (i.e., 'trust points') in the DNS tree. Each of
|
||||
those islands will be identified by the trust point name, and
|
||||
validated by at least one associated public key. For the purpose of
|
||||
this document, we'll call the association of that name and a
|
||||
particular key a 'trust anchor'. A particular trust point can have
|
||||
more than one key designated as a trust anchor.
|
||||
|
||||
For a DNSSEC-aware resolver to validate information in a DNSSEC
|
||||
protected branch of the hierarchy, it must have knowledge of a trust
|
||||
anchor applicable to that branch. It may also have more than one
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 2]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
trust anchor for any given trust point. Under current rules, a chain
|
||||
of trust for DNSSEC-protected data that chains its way back to ANY
|
||||
known trust anchor is considered 'secure'.
|
||||
|
||||
Because of the probable balkanization of the DNSSEC tree due to
|
||||
signing voids at key locations, a resolver may need to know literally
|
||||
thousands of trust anchors to perform its duties (e.g., consider an
|
||||
unsigned ".COM"). Requiring the owner of the resolver to manually
|
||||
manage these many relationships is problematic. It's even more
|
||||
problematic when considering the eventual requirement for key
|
||||
replacement/update for a given trust anchor. The mechanism described
|
||||
herein won't help with the initial configuration of the trust anchors
|
||||
in the resolvers, but should make trust point key
|
||||
replacement/rollover more viable.
|
||||
|
||||
As mentioned above, this document describes a mechanism whereby a
|
||||
resolver can update the trust anchors for a given trust point, mainly
|
||||
without human intervention at the resolver. There are some corner
|
||||
cases discussed (e.g., multiple key compromise) that may require
|
||||
manual intervention, but they should be few and far between. This
|
||||
document DOES NOT discuss the general problem of the initial
|
||||
configuration of trust anchors for the resolver.
|
||||
|
||||
1.1. Compliance Nomenclature
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in BCP 14, [RFC2119].
|
||||
|
||||
2. Theory of Operation
|
||||
|
||||
The general concept of this mechanism is that existing trust anchors
|
||||
can be used to authenticate new trust anchors at the same point in
|
||||
the DNS hierarchy. When a zone operator adds a new SEP key (i.e., a
|
||||
DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section
|
||||
2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
|
||||
validated by an existing trust anchor, then the resolver can add the
|
||||
new key to its set of valid trust anchors for that trust point.
|
||||
|
||||
There are some issues with this approach that need to be mitigated.
|
||||
For example, a compromise of one of the existing keys could allow an
|
||||
attacker to add their own 'valid' data. This implies a need for a
|
||||
method to revoke an existing key regardless of whether or not that
|
||||
key is compromised. As another example, assuming a single key
|
||||
compromise, we need to prevent an attacker from adding a new key and
|
||||
revoking all the other old keys.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 3]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
2.1. Revocation
|
||||
|
||||
Assume two trust anchor keys A and B. Assume that B has been
|
||||
compromised. Without a specific revocation bit, B could invalidate A
|
||||
simply by sending out a signed trust point key set that didn't
|
||||
contain A. To fix this, we add a mechanism that requires knowledge
|
||||
of the private key of a DNSKEY to revoke that DNSKEY.
|
||||
|
||||
A key is considered revoked when the resolver sees the key in a
|
||||
self-signed RRSet and the key has the REVOKE bit (see Section 7
|
||||
below) set to '1'. Once the resolver sees the REVOKE bit, it MUST
|
||||
NOT use this key as a trust anchor or for any other purpose except to
|
||||
validate the RRSIG it signed over the DNSKEY RRSet specifically for
|
||||
the purpose of validating the revocation. Unlike the 'Add' operation
|
||||
below, revocation is immediate and permanent upon receipt of a valid
|
||||
revocation at the resolver.
|
||||
|
||||
A self-signed RRSet is a DNSKEY RRSet that contains the specific
|
||||
DNSKEY and for which there is a corresponding validated RRSIG record.
|
||||
It's not a special DNSKEY RRSet, just a way of describing the
|
||||
validation requirements for that RRSet.
|
||||
|
||||
N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint
|
||||
than one without the bit set. This affects the matching of a DNSKEY
|
||||
to DS records in the parent [RFC3755], or the fingerprint stored at a
|
||||
resolver used to configure a trust point.
|
||||
|
||||
In the given example, the attacker could revoke B because it has
|
||||
knowledge of B's private key, but could not revoke A.
|
||||
|
||||
2.2. Add Hold-Down
|
||||
|
||||
Assume two trust point keys A and B. Assume that B has been
|
||||
compromised. An attacker could generate and add a new trust anchor
|
||||
key C (by adding C to the DNSKEY RRSet and signing it with B), and
|
||||
then invalidate the compromised key. This would result in both the
|
||||
attacker and owner being able to sign data in the zone and have it
|
||||
accepted as valid by resolvers.
|
||||
|
||||
To mitigate but not completely solve this problem, we add a hold-down
|
||||
time to the addition of the trust anchor. When the resolver sees a
|
||||
new SEP key in a validated trust point DNSKEY RRSet, the resolver
|
||||
starts an acceptance timer, and remembers all the keys that validated
|
||||
the RRSet. If the resolver ever sees the DNSKEY RRSet without the
|
||||
new key but validly signed, it stops the acceptance process for that
|
||||
key and resets the acceptance timer. If all of the keys that were
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 4]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
originally used to validate this key are revoked prior to the timer
|
||||
expiring, the resolver stops the acceptance process and resets the
|
||||
timer.
|
||||
|
||||
Once the timer expires, the new key will be added as a trust anchor
|
||||
the next time the validated RRSet with the new key is seen at the
|
||||
resolver. The resolver MUST NOT treat the new key as a trust anchor
|
||||
until the hold-down time expires AND it has retrieved and validated a
|
||||
DNSKEY RRSet after the hold-down time that contains the new key.
|
||||
|
||||
N.B.: Once the resolver has accepted a key as a trust anchor, the key
|
||||
MUST be considered a valid trust anchor by that resolver until
|
||||
explicitly revoked as described above.
|
||||
|
||||
In the given example, the zone owner can recover from a compromise by
|
||||
revoking B and adding a new key D and signing the DNSKEY RRSet with
|
||||
both A and B.
|
||||
|
||||
The reason this does not completely solve the problem has to do with
|
||||
the distributed nature of DNS. The resolver only knows what it sees.
|
||||
A determined attacker who holds one compromised key could keep a
|
||||
single resolver from realizing that the key had been compromised by
|
||||
intercepting 'real' data from the originating zone and substituting
|
||||
their own (e.g., using the example, signed only by B). This is no
|
||||
worse than the current situation assuming a compromised key.
|
||||
|
||||
2.3. Active Refresh
|
||||
|
||||
A resolver that has been configured for an automatic update of keys
|
||||
from a particular trust point MUST query that trust point (e.g., do a
|
||||
lookup for the DNSKEY RRSet and related RRSIG records) no less often
|
||||
than the lesser of 15 days, half the original TTL for the DNSKEY
|
||||
RRSet, or half the RRSIG expiration interval and no more often than
|
||||
once per hour. The expiration interval is the amount of time from
|
||||
when the RRSIG was last retrieved until the expiration time in the
|
||||
RRSIG. That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
|
||||
1/2*RRSigExpirationInterval))
|
||||
|
||||
If the query fails, the resolver MUST repeat the query until
|
||||
satisfied no more often than once an hour and no less often than the
|
||||
lesser of 1 day, 10% of the original TTL, or 10% of the original
|
||||
expiration interval. That is, retryTime = MAX (1 hour, MIN (1 day,
|
||||
.1 * origTTL, .1 * expireInterval)).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 5]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
2.4. Resolver Parameters
|
||||
|
||||
2.4.1. Add Hold-Down Time
|
||||
|
||||
The add hold-down time is 30 days or the expiration time of the
|
||||
original TTL of the first trust point DNSKEY RRSet that contained the
|
||||
new key, whichever is greater. This ensures that at least two
|
||||
validated DNSKEY RRSets that contain the new key MUST be seen by the
|
||||
resolver prior to the key's acceptance.
|
||||
|
||||
2.4.2. Remove Hold-Down Time
|
||||
|
||||
The remove hold-down time is 30 days. This parameter is solely a key
|
||||
management database bookeeping parameter. Failure to remove
|
||||
information about the state of defunct keys from the database will
|
||||
not adversely impact the security of this protocol, but may end up
|
||||
with a database cluttered with obsolete key information.
|
||||
|
||||
2.4.3. Minimum Trust Anchors per Trust Point
|
||||
|
||||
A compliant resolver MUST be able to manage at least five SEP keys
|
||||
per trust point.
|
||||
|
||||
3. Changes to DNSKEY RDATA Wire Format
|
||||
|
||||
Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag.
|
||||
If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
|
||||
signed by the associated key, then the resolver MUST consider this
|
||||
key permanently invalid for all purposes except for validating the
|
||||
revocation.
|
||||
|
||||
4. State Table
|
||||
|
||||
The most important thing to understand is the resolver's view of any
|
||||
key at a trust point. The following state table describes this view
|
||||
at various points in the key's lifetime. The table is a normative
|
||||
part of this specification. The initial state of the key is 'Start'.
|
||||
The resolver's view of the state of the key changes as various events
|
||||
occur.
|
||||
|
||||
This is the state of a trust-point key as seen from the resolver.
|
||||
The column on the left indicates the current state. The header at
|
||||
the top shows the next state. The intersection of the two shows the
|
||||
event that will cause the state to transition from the current state
|
||||
to the next.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 6]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
NEXT STATE
|
||||
--------------------------------------------------
|
||||
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
|
||||
----------------------------------------------------------
|
||||
Start | |NewKey | | | | |
|
||||
----------------------------------------------------------
|
||||
AddPend |KeyRem | |AddTime| | | |
|
||||
----------------------------------------------------------
|
||||
Valid | | | |KeyRem |Revbit | |
|
||||
----------------------------------------------------------
|
||||
Missing | | |KeyPres| |Revbit | |
|
||||
----------------------------------------------------------
|
||||
Revoked | | | | | |RemTime|
|
||||
----------------------------------------------------------
|
||||
Removed | | | | | | |
|
||||
----------------------------------------------------------
|
||||
|
||||
State Table
|
||||
|
||||
4.1. Events
|
||||
|
||||
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
|
||||
That key will become a new trust anchor for the named trust
|
||||
point after it's been present in the RRSet for at least 'add
|
||||
time'.
|
||||
|
||||
KeyPres The key has returned to the valid DNSKEY RRSet.
|
||||
|
||||
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
|
||||
this key.
|
||||
|
||||
AddTime The key has been in every valid DNSKEY RRSet seen for at
|
||||
least the 'add time'.
|
||||
|
||||
RemTime A revoked key has been missing from the trust-point DNSKEY
|
||||
RRSet for sufficient time to be removed from the trust set.
|
||||
|
||||
RevBit The key has appeared in the trust anchor DNSKEY RRSet with
|
||||
its "REVOKED" bit set, and there is an RRSig over the DNSKEY
|
||||
RRSet signed by this key.
|
||||
|
||||
4.2. States
|
||||
|
||||
Start The key doesn't yet exist as a trust anchor at the resolver.
|
||||
It may or may not exist at the zone server, but either
|
||||
hasn't yet been seen at the resolver or was seen but was
|
||||
absent from the last DNSKEY RRSet (e.g., KeyRem event).
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 7]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
AddPend The key has been seen at the resolver, has its 'SEP' bit
|
||||
set, and has been included in a validated DNSKEY RRSet.
|
||||
There is a hold-down time for the key before it can be used
|
||||
as a trust anchor.
|
||||
|
||||
Valid The key has been seen at the resolver and has been included
|
||||
in all validated DNSKEY RRSets from the time it was first
|
||||
seen through the hold-down time. It is now valid for
|
||||
verifying RRSets that arrive after the hold-down time.
|
||||
Clarification: The DNSKEY RRSet does not need to be
|
||||
continuously present at the resolver (e.g., its TTL might
|
||||
expire). If the RRSet is seen and is validated (i.e.,
|
||||
verifies against an existing trust anchor), this key MUST be
|
||||
in the RRSet, otherwise a 'KeyRem' event is triggered.
|
||||
|
||||
Missing This is an abnormal state. The key remains a valid trust-
|
||||
point key, but was not seen at the resolver in the last
|
||||
validated DNSKEY RRSet. This is an abnormal state because
|
||||
the zone operator should be using the REVOKE bit prior to
|
||||
removal.
|
||||
|
||||
Revoked This is the state a key moves to once the resolver sees an
|
||||
RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet
|
||||
contains this key with its REVOKE bit set to '1'. Once in
|
||||
this state, this key MUST permanently be considered invalid
|
||||
as a trust anchor.
|
||||
|
||||
Removed After a fairly long hold-down time, information about this
|
||||
key may be purged from the resolver. A key in the removed
|
||||
state MUST NOT be considered a valid trust anchor. (Note:
|
||||
this state is more or less equivalent to the "Start" state,
|
||||
except that it's bad practice to re-introduce previously
|
||||
used keys -- think of this as the holding state for all the
|
||||
old keys for which the resolver no longer needs to track
|
||||
state.)
|
||||
|
||||
5. Trust Point Deletion
|
||||
|
||||
A trust point that has all of its trust anchors revoked is considered
|
||||
deleted and is treated as if the trust point was never configured.
|
||||
If there are no superior configured trust points, data at and below
|
||||
the deleted trust point are considered insecure by the resolver. If
|
||||
there ARE superior configured trust points, data at and below the
|
||||
deleted trust point are evaluated with respect to the superior trust
|
||||
point(s).
|
||||
|
||||
Alternately, a trust point that is subordinate to another configured
|
||||
trust point MAY be deleted by a resolver after 180 days, where such a
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 8]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
subordinate trust point validly chains to a superior trust point.
|
||||
The decision to delete the subordinate trust anchor is a local
|
||||
configuration decision. Once the subordinate trust point is deleted,
|
||||
validation of the subordinate zone is dependent on validating the
|
||||
chain of trust to the superior trust point.
|
||||
|
||||
6. Scenarios - Informative
|
||||
|
||||
The suggested model for operation is to have one active key and one
|
||||
stand-by key at each trust point. The active key will be used to
|
||||
sign the DNSKEY RRSet. The stand-by key will not normally sign this
|
||||
RRSet, but the resolver will accept it as a trust anchor if/when it
|
||||
sees the signature on the trust point DNSKEY RRSet.
|
||||
|
||||
Since the stand-by key is not in active signing use, the associated
|
||||
private key may (and should) be provided with additional protections
|
||||
not normally available to a key that must be used frequently (e.g.,
|
||||
locked in a safe, split among many parties, etc). Notionally, the
|
||||
stand-by key should be less subject to compromise than an active key,
|
||||
but that will be dependent on operational concerns not addressed
|
||||
here.
|
||||
|
||||
6.1. Adding a Trust Anchor
|
||||
|
||||
Assume an existing trust anchor key 'A'.
|
||||
|
||||
1. Generate a new key pair.
|
||||
|
||||
2. Create a DNSKEY record from the key pair and set the SEP and Zone
|
||||
Key bits.
|
||||
|
||||
3. Add the DNSKEY to the RRSet.
|
||||
|
||||
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
|
||||
'A'.
|
||||
|
||||
5. Wait for various resolvers' timers to go off and for them to
|
||||
retrieve the new DNSKEY RRSet and signatures.
|
||||
|
||||
6. The new trust anchor will be populated at the resolvers on the
|
||||
schedule described by the state table and update algorithm -- see
|
||||
Sections 2 and 4 above.
|
||||
|
||||
6.2. Deleting a Trust Anchor
|
||||
|
||||
Assume existing trust anchors 'A' and 'B' and that you want to revoke
|
||||
and delete 'A'.
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 9]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
1. Set the revocation bit on key 'A'.
|
||||
|
||||
2. Sign the DNSKEY RRSet with both 'A' and 'B'. 'A' is now revoked.
|
||||
The operator should include the revoked 'A' in the RRSet for at
|
||||
least the remove hold-down time, but then may remove it from the
|
||||
DNSKEY RRSet.
|
||||
|
||||
6.3. Key Roll-Over
|
||||
|
||||
Assume existing keys A and B. 'A' is actively in use (i.e. has been
|
||||
signing the DNSKEY RRSet). 'B' was the stand-by key. (i.e. has been
|
||||
in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
|
||||
used to sign the RRSet).
|
||||
|
||||
1. Generate a new key pair 'C'.
|
||||
2. Add 'C' to the DNSKEY RRSet.
|
||||
3. Set the revocation bit on key 'A'.
|
||||
4. Sign the RRSet with 'A' and 'B'.
|
||||
|
||||
'A' is now revoked, 'B' is now the active key, and 'C' will be the
|
||||
stand-by key once the hold-down expires. The operator should include
|
||||
the revoked 'A' in the RRSet for at least the remove hold-down time,
|
||||
but may then remove it from the DNSKEY RRSet.
|
||||
|
||||
6.4. Active Key Compromised
|
||||
|
||||
This is the same as the mechanism for Key Roll-Over (Section 6.3)
|
||||
above, assuming 'A' is the active key.
|
||||
|
||||
6.5. Stand-by Key Compromised
|
||||
|
||||
Using the same assumptions and naming conventions as Key Roll-Over
|
||||
(Section 6.3) above:
|
||||
|
||||
1. Generate a new key pair 'C'.
|
||||
2. Add 'C' to the DNSKEY RRSet.
|
||||
3. Set the revocation bit on key 'B'.
|
||||
4. Sign the RRSet with 'A' and 'B'.
|
||||
|
||||
'B' is now revoked, 'A' remains the active key, and 'C' will be the
|
||||
stand-by key once the hold-down expires. 'B' should continue to be
|
||||
included in the RRSet for the remove hold-down time.
|
||||
|
||||
6.6. Trust Point Deletion
|
||||
|
||||
To delete a trust point that is subordinate to another configured
|
||||
trust point (e.g., example.com to .com) requires some juggling of the
|
||||
data. The specific process is:
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 10]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
1. Generate a new DNSKEY and DS record and provide the DS record to
|
||||
the parent along with DS records for the old keys.
|
||||
|
||||
2. Once the parent has published the DSs, add the new DNSKEY to the
|
||||
RRSet and revoke ALL of the old keys at the same time, while
|
||||
signing the DNSKEY RRSet with all of the old and new keys.
|
||||
|
||||
3. After 30 days, stop publishing the old, revoked keys and remove
|
||||
any corresponding DS records in the parent.
|
||||
|
||||
Revoking the old trust-point keys at the same time as adding new keys
|
||||
that chain to a superior trust prevents the resolver from adding the
|
||||
new keys as trust anchors. Adding DS records for the old keys avoids
|
||||
a race condition where either the subordinate zone becomes unsecure
|
||||
(because the trust point was deleted) or becomes bogus (because it
|
||||
didn't chain to the superior zone).
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
The IANA has assigned a bit in the DNSKEY flags field (see Section 7
|
||||
of [RFC4034]) for the REVOKE bit (8).
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
In addition to the following sections, see also Theory of Operation
|
||||
above (Section 2) and especially Section 2.2 for related discussions.
|
||||
|
||||
Security considerations for trust anchor rollover not specific to
|
||||
this protocol are discussed in [RFC4986].
|
||||
|
||||
8.1. Key Ownership vs. Acceptance Policy
|
||||
|
||||
The reader should note that, while the zone owner is responsible for
|
||||
creating and distributing keys, it's wholly the decision of the
|
||||
resolver owner as to whether to accept such keys for the
|
||||
authentication of the zone information. This implies the decision to
|
||||
update trust-anchor keys based on trusting a current trust-anchor key
|
||||
is also the resolver owner's decision.
|
||||
|
||||
The resolver owner (and resolver implementers) MAY choose to permit
|
||||
or prevent key status updates based on this mechanism for specific
|
||||
trust points. If they choose to prevent the automated updates, they
|
||||
will need to establish a mechanism for manual or other out-of-band
|
||||
updates, which are outside the scope of this document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 11]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
8.2. Multiple Key Compromise
|
||||
|
||||
This scheme permits recovery as long as at least one valid trust-
|
||||
anchor key remains uncompromised, e.g., if there are three keys, you
|
||||
can recover if two of them are compromised. The zone owner should
|
||||
determine their own level of comfort with respect to the number of
|
||||
active, valid trust anchors in a zone and should be prepared to
|
||||
implement recovery procedures once they detect a compromise. A
|
||||
manual or other out-of-band update of all resolvers will be required
|
||||
if all trust-anchor keys at a trust point are compromised.
|
||||
|
||||
8.3. Dynamic Updates
|
||||
|
||||
Allowing a resolver to update its trust anchor set based on in-band
|
||||
key information is potentially less secure than a manual process.
|
||||
However, given the nature of the DNS, the number of resolvers that
|
||||
would require update if a trust anchor key were compromised, and the
|
||||
lack of a standard management framework for DNS, this approach is no
|
||||
worse than the existing situation.
|
||||
|
||||
9. Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
|
||||
Signer (DS)", RFC 3755, May 2004.
|
||||
|
||||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements", RFC
|
||||
4033, March 2005.
|
||||
|
||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions",
|
||||
RFC 4034, March 2005.
|
||||
|
||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security
|
||||
Extensions", RFC 4035, March 2005.
|
||||
|
||||
10. Informative References
|
||||
|
||||
[RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
|
||||
"Requirements Related to DNS Security (DNSSEC) Trust
|
||||
Anchor Rollover", RFC 4986, August 2007.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 12]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Michael StJohns
|
||||
Independent
|
||||
|
||||
EMail: mstjohns@comcast.net
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 13]
|
||||
|
||||
RFC 5011 Trust Anchor Update September 2007
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The IETF Trust (2007).
|
||||
|
||||
This document is subject to the rights, licenses and restrictions
|
||||
contained in BCP 78, and except as set forth therein, the authors
|
||||
retain all their rights.
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
|
||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||||
|
||||
Intellectual Property
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
StJohns Standards Track [Page 14]
|
||||
|
||||
@@ -1,563 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group J. Jansen
|
||||
Request for Comments: 5702 NLnet Labs
|
||||
Category: Standards Track October 2009
|
||||
|
||||
|
||||
Use of SHA-2 Algorithms with RSA in
|
||||
DNSKEY and RRSIG Resource Records for DNSSEC
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes how to produce RSA/SHA-256 and RSA/SHA-512
|
||||
DNSKEY and RRSIG resource records for use in the Domain Name System
|
||||
Security Extensions (RFC 4033, RFC 4034, and RFC 4035).
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (c) 2009 IETF Trust and the persons identified as the
|
||||
document authors. All rights reserved.
|
||||
|
||||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||||
Provisions Relating to IETF Documents
|
||||
(http://trustee.ietf.org/license-info) in effect on the date of
|
||||
publication of this document. Please review these documents
|
||||
carefully, as they describe your rights and restrictions with respect
|
||||
to this document. Code Components extracted from this document must
|
||||
include Simplified BSD License text as described in Section 4.e of
|
||||
the Trust Legal Provisions and are provided without warranty as
|
||||
described in the BSD License.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 1]
|
||||
|
||||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................2
|
||||
2. DNSKEY Resource Records .........................................3
|
||||
2.1. RSA/SHA-256 DNSKEY Resource Records ........................3
|
||||
2.2. RSA/SHA-512 DNSKEY Resource Records ........................3
|
||||
3. RRSIG Resource Records ..........................................3
|
||||
3.1. RSA/SHA-256 RRSIG Resource Records .........................4
|
||||
3.2. RSA/SHA-512 RRSIG Resource Records .........................4
|
||||
4. Deployment Considerations .......................................5
|
||||
4.1. Key Sizes ..................................................5
|
||||
4.2. Signature Sizes ............................................5
|
||||
5. Implementation Considerations ...................................5
|
||||
5.1. Support for SHA-2 Signatures ...............................5
|
||||
5.2. Support for NSEC3 Denial of Existence ......................5
|
||||
6. Examples ........................................................6
|
||||
6.1. RSA/SHA-256 Key and Signature ..............................6
|
||||
6.2. RSA/SHA-512 Key and Signature ..............................7
|
||||
7. IANA Considerations .............................................8
|
||||
8. Security Considerations .........................................8
|
||||
8.1. SHA-1 versus SHA-2 Considerations for RRSIG
|
||||
Resource Records ...........................................8
|
||||
8.2. Signature Type Downgrade Attacks ...........................8
|
||||
9. Acknowledgments .................................................9
|
||||
10. References .....................................................9
|
||||
10.1. Normative References ......................................9
|
||||
10.2. Informative References ....................................9
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) is the global, hierarchical distributed
|
||||
database for Internet Naming. The DNS has been extended to use
|
||||
cryptographic keys and digital signatures for the verification of the
|
||||
authenticity and integrity of its data. [RFC4033], [RFC4034], and
|
||||
[RFC4035] describe these DNS Security Extensions, called DNSSEC.
|
||||
|
||||
RFC 4034 describes how to store DNSKEY and RRSIG resource records,
|
||||
and specifies a list of cryptographic algorithms to use. This
|
||||
document extends that list with the algorithms RSA/SHA-256 and RSA/
|
||||
SHA-512, and specifies how to store DNSKEY data and how to produce
|
||||
RRSIG resource records with these hash algorithms.
|
||||
|
||||
Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family
|
||||
of algorithms is assumed in this document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 2]
|
||||
|
||||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||||
|
||||
|
||||
To refer to both SHA-256 and SHA-512, this document will use the name
|
||||
SHA-2. This is done to improve readability. When a part of text is
|
||||
specific for either SHA-256 or SHA-512, their specific names are
|
||||
used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be
|
||||
grouped using the name RSA/SHA-2.
|
||||
|
||||
The term "SHA-2" is not officially defined but is usually used to
|
||||
refer to the collection of the algorithms SHA-224, SHA-256, SHA-384,
|
||||
and SHA-512. Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2
|
||||
will only refer to SHA-256 and SHA-512 in this document.
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||||
document are to be interpreted as described in [RFC2119].
|
||||
|
||||
2. DNSKEY Resource Records
|
||||
|
||||
The format of the DNSKEY RR can be found in [RFC4034]. [RFC3110]
|
||||
describes the use of RSA/SHA-1 for DNSSEC signatures.
|
||||
|
||||
2.1. RSA/SHA-256 DNSKEY Resource Records
|
||||
|
||||
RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
|
||||
resource records (RRs) with the algorithm number 8.
|
||||
|
||||
For interoperability, as in [RFC3110], the key size of RSA/SHA-256
|
||||
keys MUST NOT be less than 512 bits and MUST NOT be more than 4096
|
||||
bits.
|
||||
|
||||
2.2. RSA/SHA-512 DNSKEY Resource Records
|
||||
|
||||
RSA public keys for use with RSA/SHA-512 are stored in DNSKEY
|
||||
resource records (RRs) with the algorithm number 10.
|
||||
|
||||
The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and
|
||||
MUST NOT be more than 4096 bits.
|
||||
|
||||
3. RRSIG Resource Records
|
||||
|
||||
The value of the signature field in the RRSIG RR follows the RSASSA-
|
||||
PKCS1-v1_5 signature scheme and is calculated as follows. The values
|
||||
for the RDATA fields that precede the signature data are specified in
|
||||
[RFC4034].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 3]
|
||||
|
||||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||||
|
||||
|
||||
hash = SHA-XXX(data)
|
||||
|
||||
Here XXX is either 256 or 512, depending on the algorithm used, as
|
||||
specified in FIPS PUB 180-3; "data" is the wire format data of the
|
||||
resource record set that is signed, as specified in [RFC4034].
|
||||
|
||||
signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
|
||||
|
||||
Here "|" is concatenation; "00", "01", "FF", and "00" are fixed
|
||||
octets of corresponding hexadecimal value; "e" is the private
|
||||
exponent of the signing RSA key; and "n" is the public modulus of the
|
||||
signing key. The FF octet MUST be repeated the exact number of times
|
||||
so that the total length of the concatenated term in parentheses
|
||||
equals the length of the modulus of the signer's public key ("n").
|
||||
|
||||
The "prefix" is intended to make the use of standard cryptographic
|
||||
libraries easier. These specifications are taken directly from the
|
||||
specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of
|
||||
[RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2
|
||||
of [RFC3447]). The prefixes for the different algorithms are
|
||||
specified below.
|
||||
|
||||
3.1. RSA/SHA-256 RRSIG Resource Records
|
||||
|
||||
RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
|
||||
records (RRs) with algorithm number 8.
|
||||
|
||||
The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as
|
||||
specified in PKCS #1 v2.1 [RFC3447]:
|
||||
|
||||
hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
|
||||
|
||||
3.2. RSA/SHA-512 RRSIG Resource Records
|
||||
|
||||
RSA/SHA-512 signatures are stored in the DNS using RRSIG resource
|
||||
records (RRs) with algorithm number 10.
|
||||
|
||||
The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as
|
||||
specified in PKCS #1 v2.1 [RFC3447]:
|
||||
|
||||
hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 4]
|
||||
|
||||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||||
|
||||
|
||||
4. Deployment Considerations
|
||||
|
||||
4.1. Key Sizes
|
||||
|
||||
Apart from the restrictions in Section 2, this document will not
|
||||
specify what size of keys to use. That is an operational issue and
|
||||
depends largely on the environment and intended use. A good starting
|
||||
point for more information would be NIST SP 800-57 [NIST800-57].
|
||||
|
||||
4.2. Signature Sizes
|
||||
|
||||
In this family of signing algorithms, the size of signatures is
|
||||
related to the size of the key and not to the hashing algorithm used
|
||||
in the signing process. Therefore, RRSIG resource records produced
|
||||
with RSA/SHA-256 or RSA/SHA-512 will have the same size as those
|
||||
produced with RSA/SHA-1, if the keys have the same length.
|
||||
|
||||
5. Implementation Considerations
|
||||
|
||||
5.1. Support for SHA-2 Signatures
|
||||
|
||||
DNSSEC-aware implementations SHOULD be able to support RRSIG and
|
||||
DNSKEY resource records created with the RSA/SHA-2 algorithms as
|
||||
defined in this document.
|
||||
|
||||
5.2. Support for NSEC3 Denial of Existence
|
||||
|
||||
[RFC5155] defines new algorithm identifiers for existing signing
|
||||
algorithms, to indicate that zones signed with these algorithm
|
||||
identifiers can use NSEC3 as well as NSEC records to provide denial
|
||||
of existence. That mechanism was chosen to protect implementations
|
||||
predating RFC 5155 from encountering resource records about which
|
||||
they could not know. This document does not define such algorithm
|
||||
aliases.
|
||||
|
||||
A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate
|
||||
negative answers in the form of both NSEC and NSEC3 with hash
|
||||
algorithm 1, as defined in [RFC5155]. An authoritative server that
|
||||
does not implement NSEC3 MAY still serve zones that use RSA/SHA-2
|
||||
with NSEC denial of existence.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 5]
|
||||
|
||||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||||
|
||||
|
||||
6. Examples
|
||||
|
||||
6.1. RSA/SHA-256 Key and Signature
|
||||
|
||||
Given a private key with the following values (in Base64):
|
||||
|
||||
Private-key-format: v1.2
|
||||
Algorithm: 8 (RSASHA256)
|
||||
Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm
|
||||
idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q==
|
||||
PublicExponent: AQAB
|
||||
PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/
|
||||
HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ==
|
||||
Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk=
|
||||
Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE=
|
||||
Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk=
|
||||
Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE=
|
||||
Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q=
|
||||
|
||||
The DNSKEY record for this key would be:
|
||||
|
||||
example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI
|
||||
my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P
|
||||
kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b}
|
||||
|
||||
With this key, sign the following RRSet, consisting of 1 A record:
|
||||
|
||||
www.example.net. 3600 IN A 192.0.2.91
|
||||
|
||||
If the inception date is set at 00:00 hours on January 1st, 2000, and
|
||||
the expiration date at 00:00 hours on January 1st, 2030, the
|
||||
following signature should be created:
|
||||
|
||||
www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000
|
||||
20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9
|
||||
l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa
|
||||
cFYK/lPtPiVYP4bwg==);{id = 9033}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 6]
|
||||
|
||||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||||
|
||||
|
||||
6.2. RSA/SHA-512 Key and Signature
|
||||
|
||||
Given a private key with the following values (in Base64):
|
||||
|
||||
Private-key-format: v1.2
|
||||
Algorithm: 10 (RSASHA512)
|
||||
Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf
|
||||
Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk
|
||||
8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V
|
||||
jXZlNKdyit99waaE4s=
|
||||
PublicExponent: AQAB
|
||||
PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6
|
||||
AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj
|
||||
yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3
|
||||
SEIAsrB043XzGrKIVE=
|
||||
Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x
|
||||
nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ==
|
||||
Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK
|
||||
Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw==
|
||||
Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM
|
||||
MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q==
|
||||
Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J
|
||||
PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w==
|
||||
Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q
|
||||
/Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ==
|
||||
|
||||
The DNSKEY record for this key would be:
|
||||
|
||||
example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD
|
||||
p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD
|
||||
xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g
|
||||
pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL
|
||||
);{id = 3740 (zsk), size = 1024b}
|
||||
|
||||
With this key, sign the following RRSet, consisting of 1 A record:
|
||||
|
||||
www.example.net. 3600 IN A 192.0.2.91
|
||||
|
||||
If the inception date is set at 00:00 hours on January 1st, 2000, and
|
||||
the expiration date at 00:00 hours on January 1st, 2030, the
|
||||
following signature should be created:
|
||||
|
||||
www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000
|
||||
20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t
|
||||
6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa
|
||||
eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL
|
||||
DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw
|
||||
=);{id = 3740}
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 7]
|
||||
|
||||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||||
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
This document updates the IANA registry "DNS SECURITY ALGORITHM
|
||||
NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols). The
|
||||
following entries are added to the registry:
|
||||
|
||||
Zone Trans.
|
||||
Value Description Mnemonic Signing Sec. References
|
||||
8 RSA/SHA-256 RSASHA256 Y * RFC 5702
|
||||
10 RSA/SHA-512 RSASHA512 Y * RFC 5702
|
||||
|
||||
* There has been no determination of standardization of the use of
|
||||
this algorithm with Transaction Security.
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
8.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records
|
||||
|
||||
Users of DNSSEC are encouraged to deploy SHA-2 as soon as software
|
||||
implementations allow for it. SHA-2 is widely believed to be more
|
||||
resilient to attack than SHA-1, and confidence in SHA-1's strength is
|
||||
being eroded by recently announced attacks. Regardless of whether or
|
||||
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
|
||||
time of this writing) that SHA-2 is the better choice for use in
|
||||
DNSSEC records.
|
||||
|
||||
SHA-2 is considered sufficiently strong for the immediate future, but
|
||||
predictions about future development in cryptography and
|
||||
cryptanalysis are beyond the scope of this document.
|
||||
|
||||
The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one
|
||||
used for RSA/SHA-1 signatures. This should ease implementation of
|
||||
the new hashing algorithms in DNSSEC software.
|
||||
|
||||
8.2. Signature Type Downgrade Attacks
|
||||
|
||||
Since each RRSet MUST be signed with each algorithm present in the
|
||||
DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a
|
||||
malicious party cannot filter out the RSA/SHA-2 RRSIG and force the
|
||||
validator to use the RSA/SHA-1 signature if both are present in the
|
||||
zone. This should provide resilience against algorithm downgrade
|
||||
attacks, if the validator supports RSA/SHA-2.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 8]
|
||||
|
||||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||||
|
||||
|
||||
9. Acknowledgments
|
||||
|
||||
This document is a minor extension to [RFC4034]. Also, we try to
|
||||
follow the documents [RFC3110] and [RFC4509] for consistency. The
|
||||
authors of and contributors to these documents are gratefully
|
||||
acknowledged for their hard work.
|
||||
|
||||
The following people provided additional feedback and text: Jaap
|
||||
Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont,
|
||||
Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose,
|
||||
Michael St. Johns, and Wouter Wijngaards.
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[FIPS.180-3.2008]
|
||||
National Institute of Standards and Technology, "Secure
|
||||
Hash Standard", FIPS PUB 180-3, October 2008.
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
|
||||
Name System (DNS)", RFC 3110, May 2001.
|
||||
|
||||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements",
|
||||
RFC 4033, March 2005.
|
||||
|
||||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions",
|
||||
RFC 4034, March 2005.
|
||||
|
||||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security
|
||||
Extensions", RFC 4035, March 2005.
|
||||
|
||||
10.2. Informative References
|
||||
|
||||
[NIST800-57]
|
||||
Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
|
||||
"Recommendations for Key Management", NIST SP 800-57,
|
||||
March 2007.
|
||||
|
||||
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
|
||||
Standards (PKCS) #1: RSA Cryptography Specifications
|
||||
Version 2.1", RFC 3447, February 2003.
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 9]
|
||||
|
||||
RFC 5702 DNSSEC RSA/SHA-2 October 2009
|
||||
|
||||
|
||||
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
|
||||
(DS) Resource Records (RRs)", RFC 4509, May 2006.
|
||||
|
||||
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
|
||||
Security (DNSSEC) Hashed Authenticated Denial of
|
||||
Existence", RFC 5155, March 2008.
|
||||
|
||||
Author's Address
|
||||
|
||||
Jelte Jansen
|
||||
NLnet Labs
|
||||
Science Park 140
|
||||
1098 XG Amsterdam
|
||||
NL
|
||||
|
||||
EMail: jelte@NLnetLabs.nl
|
||||
URI: http://www.nlnetlabs.nl/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Jansen Standards Track [Page 10]
|
||||
|
||||
Reference in New Issue
Block a user