Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
989256b896 |
@@ -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 ]
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -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,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>
|
||||
@@ -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,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]
|
||||
|
||||
Reference in New Issue
Block a user