From: cvs2git Date: Fri, 14 Aug 2009 07:55:22 +0000 (+0000) Subject: This commit was manufactured by cvs2git to create tag 'v9_5_2b1'. X-Git-Tag: v9.5.2b1^0 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8e29f7f28a01ea2d10fc6f6d2a3bbdd30f80226b;p=thirdparty%2Fbind9.git This commit was manufactured by cvs2git to create tag 'v9_5_2b1'. --- diff --git a/doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt b/doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt deleted file mode 100644 index 3e08247f692..00000000000 --- a/doc/draft/draft-dolmatov-dnsext-dnssec-gost-00.txt +++ /dev/null @@ -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 (256||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 ] - - diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt deleted file mode 100644 index 5278587ddb3..00000000000 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-11.txt +++ /dev/null @@ -1,1058 +0,0 @@ -DNS Extensions Working Group Edward Lewis -INTERNET-DRAFT NeuStar, Inc. -Expires: Octopber 1, 2009 April 2009 -Updates: 1034, 1035 (if approved) -Intended status: Standards Track - - DNS Zone Transfer Protocol (AXFR) - draft-ietf-dnsext-axfr-clarify-11.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - This Internet-Draft will expire on October 1, 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 - -The Domain Name System standard mechanisms for maintaining coherent -servers for a zone consist of three elements. One mechanism is the -Authoritative Transfer (AXFR) is defined in RFC 1034 and RFC 1035. -The definition of AXFR, has proven insufficient in detail, forcing -implementations intended to be compliant to make assumptions, impeding -interoperability. Yet today we have a satisfactory set of -implementations that do interoperate. This document is a new -definition of the AXFR, new in the sense that is it recording an -accurate definition of an interoperable AXFR mechanism. - -1 Introduction - -The Domain Name System standard facilities for maintaining coherent -servers for a zone consist of three elements. Authoritative -Transfer (AXFR) is defined in "Domain Names - Concepts and Facilities" -[RFC1034] (referred to in this document as RFC 1034) and "Domain Names -- Implementation and Specification" [RFC1035] (aka RFC 1035). -Incremental Zone Transfer (IXFR) is defined in "Incremental Zone -Transfer in DNS" [RFC1995]. A mechanism for prompt notification of -zone changes (NOTIFY) is defined in "A Mechanism for Prompt -Notification of Zone Changes (DNS NOTIFY)" [RFC1996]. The goal of -these mechanisms is to enable a set of DNS name servers to remain -coherently authoritative for a given zone. - -Comments on this draft ought to be addressed to the editor or to -namedroppers@ops.ietf.org. - -1.1 Definition of Terms - -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 "Key words for use in -RFCs to Indicate Requirement Levels" [BCP14]. - -"Newer"/"New" DNS and "older"/"old" DNS refers to implementations -written after and prior to the publication of this document. - -1.2 Scope - -In the greater context there are many ways to achieve coherency among -a set of name servers. The AXFR, IXFR and NOTIFY mechanisms form -just one, the one defined in the RFCs cited. For example, there are -DNS implementations that assemble answers from data stored in -relational databases (as opposed to master files) relying on the -database's non-DNS means to synchronize the database instances. Some -of these non-DNS solutions interoperate in some fashion. As far as -it is known, AXFR, IXFR and NOTIFY are the only in-band mechanisms -that provide an interoperable solution to the desire for coherency -within the definition of DNS, they certainly are the only mechanisms -documented by the IETF. - -This document does not cover incoherent DNS situations. There are -applications of the DNS in which servers for a zone are designed to be -incoherent. For these configurations, a coherency mechanism as -described here would be unsuitable. - -"General purpose DNS implementation" refers to DNS software developed -for wide-spread use. This includes resolvers and servers freely -accessible as libraries and standalone processes. This also includes -proprietary implementations used only in support of DNS service -offerings. - -"Turnkey DNS implementation" refers to custom made, single use -implementations of DNS. Such implementations consist of software -that employs the DNS protocol message format yet do not conform to -the entire range of DNS functionality. - -A DNS implementation is not required to support AXFR, IXFR and NOTIFY. -A DNS implementation SHOULD have some means for maintaining name server -coherency. A general purpose DNS implementation SHOULD include AXFR -(and in the same vein IXFR and NOTIFY), but turnkey DNS implementations -MAY exist without AXFR. (An editorial note to readers of this section. -The mention of IXFR and NOTIFY is for context and illustration, this -document does not make any normative comments on those mechanisms.) - -1.3 Context - -Besides describing the mechanisms themselves, there is the context in -which they operate to consider. When AXFR, IXFR and NOTIFY were -defined, there was little consideration given to security and privacy -issues. Since the original definition of AXFR, new opinions have -appeared on the access to an entire zone's contents. In this document, -the basic mechanisms will be discussed separately from the permission -to use these mechanisms. - -1.4 Coverage and Relationship to Original AXFR Specification - -This document concentrates on just the definition of AXFR. Any effort -to update the IXFR or NOTIFY mechanisms would be done in different -documents. - -The original "specification" of the AXFR sub-protocol is scattered -through RFC 1034 and RFC 1035. Section 2.2 of RFC 1035 on page 5 -depicts the scenario for which AXFR has been designed. Section 4.3.5 -of RFC 1034 describes the zone synchronization strategies in general -and rules for the invocation of a full zone transfer via AXFR; the -fifth paragraph of that section contains a very short sketch of the -AXFR protocol; Section 5.5 of RFC 2181 has corrected a significant -flaw in that specification. Section 3.2.3 of RFC 1035 has assigned -the code point for the AXFR QTYPE (see section 2.1.2 below for more -details). Section 4.2 of RFC 1035 discusses the transport layer use -of DNS and shortly explains why UDP transport is deemed inappropriate -for AXFR; the last paragraph of Section 4.2.2 gives details for the -TCP connection management with AXFR. Finally, the second paragraph -of Section 6.3 in RFC 1035 mandates server behavior when zone data -changes occur during an ongoing zone transfer using AXFR. - -This document will update the specification of AXFR in fully -specifying the record formats and processing rules for AXFR, largely -expanding on paragraph 5 of Section 4.3.5 of RFC 1034, and detailing -the transport considerations for AXFR, thus amending Section 4.2.2 of -RFC 1035. Furthermore, it discusses backward compatibility issues -and provides policy/management considerations as well as specific -Security Considerations for AXFR. The goal of this document is to -define AXFR as it exists, or is supposed to exist, currently. - -2 AXFR Messages - -An AXFR session consists of an AXFR query message and the sequence of -AXFR response messages returned for it. In this document, the AXFR -client is the sender of the AXFR query and the AXFR server is the -responder. (Use of terms such as master, slave, primary, secondary -are not important to defining AXFR.) The use of the word "session" -without qualification refers to an AXFR session. - -An important aspect to keep in mind is that the definition of AXFR is -restricted to TCP [RFC0793]. The design of the AXFR process has -certain inherent features that are not easily ported to UDP [RFC0768]. - -The basic format of an AXFR message is the DNS message as defined in -RFC 1035, Section 4 ("MESSAGES") [RFC1035], updated by the following: -- "A Mechanism for Prompt Notification of Zone Changes (...)" [RFC1996] -- "Domain Name System (DNS) IANA Considerations" [RFC5395] -- "Dynamic Updates in the Domain Name System (DNS UPDATE)" [RFC2136] -- "Clarifications to the DNS Specification" [RFC2181] -- "Extension Mechanisms for DNS (EDNS0)" [RFC2671] -- "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] -- "Secret Key Establishment for DNS (TKEY RR)" [RFC2930] -- "Obsoleting IQUERY" [RFC3425] -- "Handling of Unknown DNS Resource Record (RR) Types" [RFC3597] -- "Resource Records for the DNS Security Extensions" [RFC4034] -- "Protocol Modifications for the DNS Security Extensions" [RFC4035] -- "Use of SHA-256 in DNSSEC ... (DS) ... (RRs)" [RFC4509] -- "HMAC SHA TSIG Algorithm Identifiers" [RFC4635] -- "... (DNSSEC) Hashed Authenticated Denial of Existence" [RFC5155] - -For completeness, the following, in process, documents contain -information about the DNS message. These documents ought not interfere -with AXFR but these documents are helpful in understanding what will -be carried via AXFR. - -- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource - Records for DNSSEC" [DRAFT1] -- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2] - -The upper limit on the permissible size of a DNS message over TCP is -only restricted by the TCP framing defined in RFC 1035, section 4.2.2 -which specifies a two-octet message length field, understood to be -unsigned, and thus causing a limit of 65535 octets. Unlike DNS -messages over UDP, this limit is not changed by EDNS0. - -Note that the TC (truncation) bit is never set by an AXFR server nor -considered/read by an AXFR client. - -Field names used in this document will correspond to the names as they -appear in the IANA registry for DNS Header Flags [DNSFLGS]. - -2.1 AXFR query - -An AXFR query is sent by a client whenever there is a reason to ask. -This might be because of zone maintenance activities or as a result of -a command line request, say for debugging. - -An AXFR query is sent by a client whenever there is a reason to ask. -This might be because of scheduled or triggered zone maintenance -activities (see section 4.3.5 of RFC 1034 and DNS NOTIFY [RFC1996], -respectively) or as a result of a command line request, say for -debugging. - -2.1.1 Header Values - -These are the DNS message header values for an AXFR query. - -ID See note 2.1.1.a -QR MUST be 0 (Query) -OPCODE MUST be 0 (Standard Query) -AA See note 2.1.1.b -TC See note 2.1.1.b -RD See note 2.1.1.b -RA See note 2.1.1.b -Z See note 2.1.1.c -AD See note 2.1.1.b -CD See note 2.1.1.b -RCODE MUST be 0 (No error) -QDCOUNT MUST be 1 -ANCOUNT MUST be 0 -NSCOUNT MUST be 0 -ARCOUNT See note 2.1.1.d - -Note 2.1.1.a Set to any value that the client is not already using -with the same server. There is no specific means for selecting the -value in this field. (Recall that AXFR is done only via TCP -connections.) - -A server MUST reply using messages that use the same message ID to -allow a client to meaningfully have multiple AXFR queries outstanding. - -Note 2.1.1.b The value in this field has no meaning in the context of -AXFR query messages. For the client, it is RECOMMENDED that the -value be zero. The server MUST ignore this value. - -Note 2.1.1.c The client MUST set this bit to 0, the server MUST ignore -it. - -Note 2.1.1.d The client MUST set this field to be the number of -resource records appearing in the additional section. See Section -2.1.5 "Additional Section" for details. - -The value MAY be 0, 1 or 2. If it is 2, the additional -section MUST contain both an EDNS0 [RFC2671] OPT resource record and -a record carrying transaction integrity and authentication data, -currently a choice of TSIG [RFC2845] and SIG(0) [RFC2931]. If the -value is 1, then the additional section MUST contain either only an -EDNS0 OPT resource record or a record carrying transaction integrity -and authentication data. If the value is 0, the additional section -MUST be empty. - -2.1.2 Query Section - -The Query section of the AXFR query MUST conform to section 4.1.2 of -RFC 1035, and contain the following values: - -QNAME the name of the zone requested -QTYPE AXFR(= 252), the pseudo-RR type for zone transfer [DNSVALS] -QCLASS the class of the zone requested - -2.1.3 Answer Section - -MUST be empty. - -2.1.4 Authority Section - -MUST be empty. - -2.1.5 Additional Section - -The client MAY include an EDNS0 OPT [RFC2671] resource record. If the -server has indicated that it does not support EDNS0, the client MUST -send this section without an EDNS0 OPT resource record if there is a -retry. Indication that a server does not support EDNS0 is not an -explicit element in the protocol, it is up to the client to interpret. -Most likely, the server will return a FORMERR which might be related to -the OPT resource record. - -The client MAY include a transaction integrity and authentication -resource record, currently a choice of TSIG [RFC2845] or SIG(0) -[RFC2931]. If the server has indicated that it does not recognize the -resource record, and that the error is indeed caused by the resource -record, the client probably ought not try again. Removing the security -data in the face of an obstacle ought to only be done with full -awareness of the implication of doing so. - -In general, if an AXFR client is aware that an AXFR server does not -support a particular mechanism, the client SHOULD NOT attempt to engage -the server using the mechanism (or at all). A client could become -aware of a server's abilities via a configuration setting or via some -other (as yet) undefined means. - -The range of permissible resource records that MAY appear in the -additional section might change over time. If either a change to an -existing resource record (like the OPT RR for EDNS0) is made or -a new additional section record is created, the new definitions ought -to include a discussion on the impact upon AXFR. Although this is not -predictable, future additional section residing records may have an -effect that is orthogonal to AXFR, so can ride through the session as -opaque data. In this case, a "wise" implementation ought to be able -to pass these records through without disruption. - -2.2 AXFR response - -The AXFR response will consist of 0 or more messages. A "0 message" -response is covered in section 2.2.1. - -An AXFR response that is transferring the zone's contents will consist -of a series (which could be a series of length 1) of DNS messages. -In such a series, the first message MUST begin with the SOA -resource record of the zone, the last message MUST conclude with the -same SOA resource record. Intermediate messages MUST NOT contain the -SOA resource record. The first message MUST copy the Query Section -from the corresponding AXFR query message in to the first response -message's query section. Subsequent messages MAY do the same. - -An AXFR response that is indicating an error MUST consist of a single -DNS message with the return code set to the appropriate value for the -condition encountered - once the error condition is detected. Such -a message MUST terminate the AXFR session; it MUST copy the Query -Section from the AXFR query into its Query Section, but the inclusion -of the terminating SOA resource record is not necessary. - -An AXFR client might receive a number of AXFR response messages -free of an error condition before the message indicating an error -is received. - -2.2.1 "0 Message" Response - -A legitimate "0 message" response, i.e., the client sees no response -whatsoever, is very exceptional and controversial. Unquestionably it -is unhealthy for there to be 0 responses in a protocol that is designed -around a query - response paradigm over an unreliable transport. The -lack of a response could be a sign of underlying network problems and -cause the protocol state machine to react accordingly. However, AXFR -uses TCP and not UDP, eliminating undetectable network errors. - -A "0 message response" is reserved for situations in which the server -has a reason to suspect that the query is sent for the purpose of -abuse. Due to the use of this being so controversial, a "0 message -response" is not being defined as a legitimate part of the protocol -but the use of it is being acknowledged as a warning to AXFR client -implementations. Any earnest query has the expectation of some -response but may not get one. - -2.2.2 Header Values - -ID See note 2.2.2.a -QR MUST be 1 (Response) -OPCODE MUST be 0 (Standard Query) -AA See note 2.2.2.b -TC MUST be 0 (Not truncated) -RD RECOMMENDED copy request's value, MAY be set to 0 -RA See note 2.2.2.c -Z See note 2.2.2.d -AD See note 2.2.2.e -CD See note 2.2.2.e -RCODE See note 2.2.2.f -QDCOUNT MUST be 1 in the first message; MUST be 0 or 1 in all - following -ANCOUNT See note 2.2.2.g -NSCOUNT MUST be 0 -ARCOUNT See note 2.2.2.h - -Note 2.2.2.a Because some old implementations behave differently than -is now desired, the requirement on this field is stated in detail. -New DNS servers MUST set this field to the value of the AXFR query -ID in each AXFR response message for the session. AXFR clients MUST -be able to manage sessions resulting from the issuance of multiple -outstanding queries, whether AXFR queries or other DNS queries. A -client SHOULD discard responses that do not correspond (via the -message ID) to any outstanding queries. - -Unless the client is sure that the server will consistently set the ID -field to the query's ID, the client is NOT RECOMMENDED to issue any -other queries until the end of the zone transfer. A client MAY become -aware of a server's abilities via a configuration setting. - -Note 2.2.2.b If the RCODE is 0 (no error), then the AA bit MUST be 1. -For any other value of RCODE, the AA bit MUST be set according to rules -for that error code. If in doubt, it is RECOMMENDED that it be set -to 1. It is RECOMMENDED that the value be ignored by the AXFR client. - -Note 2.2.2.c It is RECOMMENDED that the server set the value to 0, -the client MUST ignore this value. - -The server MAY set this value according to the local policy regarding -recursive service, but doing so might confuse the interpretation of the -response as AXFR can not be retrieved recursively. A client MAY note -the server's policy regarding recursive service from this value, but -SHOULD NOT conclude that the AXFR response was obtained recursively -even if the RD bit was 1 in the query. - -Note 2.2.2.d The server MUST set this bit to 0, the client MUST ignore -it. - -Note 2.2.2.e If the implementation supports the DNS Security Extensions -(see below) then this value MUST be set according to the rules in RFC -4035, section 3.1.6, "The AD and CD Bits in an Authoritative Response". -If the implementation does not support the DNS Security Extensions, -then this value MUST be set to 0 and MUST be ignored upon receipt. - -The DNS Security Extensions (DNSSEC) is defined in these base -documents: -- "DNS Security Introduction and Requirements" [RFC4033] -- "Resource Records for the DNS Security Extensions" [RFC4034] -- "Protocol Modifications for the DNS Security Extensions" [RFC4035] -- "Use of SHA-256 in DNSSEC Delegation Signer RRs" [RFC4509] -- "DNS Security Hashed Authenticated Denial of Existence" [RFC5155] - -as well pending documents, such as these: - -- "Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource - Records for DNSSEC" [DRAFT1] -- "Clarifications and Implementation Notes for DNSSECbis" [DRAFT2] - -Note 2.2.2.f In the absence of an error, the server MUST set the value -of this field to NoError. If a server is not authoritative for the -queried zone, the server SHOULD set the value to NotAuth. (Reminder, -consult the appropriate IANA registry [DNSVALS].) If a client -receives any other value in response, it MUST act according to the -error. For example, a malformed AXFR query or the presence of an EDNS0 -OPT resource record sent to an old server will garner a FormErr value. -This value is not set as part of the AXFR-specific response processing. -The same is true for other error-indicating values. - -Note 2.2.2.g The count of answer records MUST equal the number of -resource records in the AXFR Answer Section. When a server is aware -that a client will only accept one resource record per response -message, then the value MUST be 1. A server MAY be made aware of a -client's limitations via configuration data. - -Note 2.2.2.h The client MUST set this field to be the number of -resource records appearing in the additional section. The -considerations in Note 2.1.1.d above apply equally; see Section -2.2.6 "Additional Section" below for more details. - -2.2.3 Query Section - -In the first response message, this section MUST be copied from the -query. In subsequent messages, this section MAY be copied from the -query or it MAY be empty. The content of this section MAY be used to -determine the context of the message, that is, the name of the zone -being transferred. - -2.2.4 Answer Section - -MUST be populated with the zone contents. See later section on -encoding zone contents. - -2.2.5 Authority Section - -MUST be empty. - -2.2.6 Additional Section - -The contents of this section MUST follow the guidelines for EDNS0, -TSIG, SIG(0), or what ever other future record is possible here. The -contents of section 2.1.5 apply here as well. - -2.3 TCP Connection Aborts - -If an AXFR client sends a query on a TCP connection and the connection -is closed at any point, the AXFR client MUST consider the AXFR session -terminated. The message ID MAY be used again on a new connection, -even if the question and AXFR server are the same. Facing a dropped -connection a client SHOULD try to make some determination whether the -connection closure was the result of network activity or a decision -by the AXFR server. This determination is not an exact science. It -is up to the AXFR client implementor to react, but the reaction -SHOULD NOT be an endless cycle of retries nor an increasing (in -frequency) retry rate. - -An AXFR server implementor SHOULD take into consideration the dilemma -described above when a connection is closed with an outstanding query -in the pipeline. For this reason, a server ought to reserve this -course of action for situations in which it believes beyond a doubt -that the AXFR client is attempting abusive behavior. - -3 Zone Contents - -The objective of the AXFR session is to request and transfer the -contents of a zone. The objective is to permit the AXFR client to -reconstruct the zone as it exists at the server for the given zone -serial number. Over time the definition of a zone has evolved from -denoting a static set of records to also cover a dynamically updated -set of records, and then a potentially continually regenerated set of -records as well. - -3.1 Records to Include - -In the answer section of AXFR response messages the resource records -within a zone for the given serial number MUST appear. The definition -of what belongs in a zone is described in RFC 1034, Section 4.2, "How -the database is divided into zones", in particular, section 4.2.1, -"Technical considerations", and it has been clarified in Section 6 of -RFC 2181. - -Unless the AXFR server knows that the AXFR client is old and expects -just one resource record per AXFR response message, an AXFR server -SHOULD populate an AXFR response message with as many complete -resource record sets as will fit within a DNS message. - -Zones for which it is impractical to list the entire zones for a serial -number are not suitable for AXFR retrieval. A typical (but not -limiting) description of such a zone is a zone consisting of responses -generated via other database lookups and/or computed based upon ever -changing data. - -3.2 Delegation Records - -In RFC 1034, section 4.2.1, this text appears (keep in mind that the -"should" in the quotation predates [BCP14], cf. section 1.1) "The RRs -that describe cuts ... should be exactly the same as the corresponding -RRs in the top node of the subzone." There has been some controversy -over this statement and the impact on which NS resource records are -included in a zone transfer. - -The phrase "that describe cuts" is a reference to the NS set and -applicable glue records. It does not mean that the cut point and apex -resource records are identical. For example, the SOA resource record -is only found at the apex. The discussion here is restricted to just -the NS resource record set and glue as these "describe cuts". - -DNSSEC resource records have special specifications regarding their -occurrence at a zone cut and the apex of a zone. This has for the -first time been described in Sections 5.3 ff. and 6.2 of RFC 2181 -(for the initial specification of DNSSEC), which now is historical. -The current DNSSEC core document set (see Note 2.2.2.e above) gives -the full details for DNSSEC(bis) resource record placement, and -Section 3.1.5 of RFC 4035 normatively specifies their treatment during -AXFR; the alternate NSEC3 resource record defined later in RFC 5155 -behaves identically as the NSEC RR, for the purpose of AXFR. - -Informally: -o The DS RRSet only occurs at the parental side of a zone cut and is - authoritative data in the parent zone, not the secure child zone. -o The DNSKEY RRSet only occurs at the APEX of a signed zone and is - authoritative part of the zone it serves. -o Independent RRSIG RRSets occur at the signed parent side and of a - zone cut and at the apex of a signed zone; they are authoritative - part of the respective zone; simple queries for RRSIG resource - records may return bth RRSets at once if the same server is - authoritative for the parent zone and the child zone (Section - 3.1.5 of RFC 4035 describes how to distinguish these RRs); this - seeming ambiguity does not occur for AXFR, since each such RRSIG - RRset belongs to a single zone. -o Different NSEC [RFC4034] or NSEC3 [RFC5155] resource records - equally may occur at the parental siede of a zone cut and at the - apex of a zone; each such resource record belongs to exactly one - of these zones and is to be included in the AXFR of that zone. - -The issue is that in operations there are times when the NS resource -records for a zone might be different at a cut point in the parent and -at the apex of a zone. Sometimes this is the result of an error and -sometimes it is part of an ongoing change in name servers. The DNS -protocol is robust enough to overcome inconsistencies up to (but not -including) there being no parent indicated NS resource record -referencing a server that is able to serve the child zone. This -robustness is one quality that has fueled the success of the DNS. -Still, the inconsistency is an error state and steps need to be taken -to make it apparent (if it is unplanned) and to make it clear once -the inconsistency has been removed. - -Another issue is that the AXFR server could be authoritative for a -different set of zones than the AXFR client. It is possible that the -AXFR server be authoritative for both halves of an inconsistent cut -point and that the AXFR client is authoritative for just the parent of -the cut point. - -The question that arises is, when facing a situation in which a cut -point's NS resource records do not match the authoritative set, whether -an AXFR server responds with the NS resource record set that is in the -zone being transferred or is at the authoritative location. - -The AXFR response MUST contain the cut point NS resource record set -registered with the zone whether it agrees with the authoritative set -or not. "Registered with" can be widely interpreted to include data -residing in the zone file of the zone for the particular serial -number (in zone file environments) or as any data configured to be in -the zone (database), statically or dynamically. - -The reasons for this requirement are: - -1) The AXFR server might not be able to determine that there is an -inconsistency given local data, hence requiring consistency would mean -a lot more needed work and even network retrieval of data. An -authoritative server ought not be required to perform any queries. - -2) By transferring the inconsistent NS resource records from a server -that is authoritative for both the cut point and the apex to a client -that is not authoritative for both, the error is exposed. For example, -an authorized administrator can manually request the AXFR and inspect -the results to see the inconsistent records. (A server authoritative -for both halves would otherwise always answer from the more -authoritative set, concealing the error.) - -3) The inconsistent NS resource record set might indicate a problem -in a registration database. - -4) This requirement is necessary to ensure that retrieving a given -(zone,serial) pair by AXFR yields the exact same set of resource -records no matter which of the zone's authoritative servers is -chosen as the source of the transfer. - -If an AXFR server were allowed to respond with the authoritative -NS RRset of a child zone instead of a glue NS RRset in the zone -being transferred, the set of records returned could vary depending -on whether or not the server happens to also be authoritative for -the child zone. - -The property that a given (zone,serial) pair corresponds to a -single, well-defined set of records is necessary for the correct -operation of incremental transfer protocols such as IXFR -[RFC1995]. For example, a client may retrieve a zone by AXFR from -one server, and then apply an incremental change obtained by IXFR -from a different server. If the two servers have different ideas -of the zone contents, the client can end up attempting to -incrementally add records that already exist or to delete records -that do not exist. - -3.3 Glue Records - -As quoted in the previous section, section 4.2.1 of RFC 1034 provides -guidance and rationale for the inclusion of glue records as part of -an AXFR transfer. And, as also argued in the previous section of this -document, even when there is an inconsistency between the address in a -glue record and the authoritative copy of the name server's address, -the glue resource record that is registered as part of the zone for -that serial number is to be included. - -This applies to glue records for any address family [RFC1700]. - -The AXFR response MUST contain the appropriate glue records as -registered with the zone. The interpretation of "registered with" -in the previous section applies here. Inconsistent glue records are -an operational matter. - -3.4 Name Compression - -Compression of names in DNS messages is described in RFC 1035, section -4.1.4, "Message compression". The issue highlighted here relates to a -comment made in RFC 1034, section 3.1, "Name space specifications and -terminology" which says "When you receive a domain name or label, you -should preserve its case." ("Should" in the quote predates [BCP14].) - -Name compression in an AXFR message MUST preserve the case of the -original domain name. That is, although when comparing a domain name, -"a" equals "A", when comparing for the purposes of message compression, -"a" is not equal to "A". Note that this is not the usual definition -of name comparison in the DNS protocol and represents a new -requirement on AXFR servers. - -Rules governing name compression of RDATA in an AXFR message MUST -abide by the specification in "Handling of Unknown DNS Resource Record -(RR) Types" [RFC3597], specifically, section 4 on "Domain Name -Compression." - -3.5 Occluded Names - -Dynamic Update [RFC2136] operations, and in particular its interaction -with DNAME [RFC2672], can have a side effect of occluding names in a -zone. The addition of a delegation point via dynamic update will -render all subordinate domain names to be in a limbo, still part of -the zone but not available to the lookup process. The addition of a -DNAME resource record has the same impact. The subordinate names are -said to be "occluded." - -Occluded names MUST be included in AXFR responses. An AXFR client MUST -be able to identify and handle occluded names. The rationale for this -action is based on a speedy recovery if the dynamic update operation -was in error and is to be undone. - -4 Transport - -AXFR sessions are currently restricted to TCP by section 4.3.5 of RFC -1034 that states: "Because accuracy is essential, TCP or some other -reliable protocol must be used for AXFR requests." The restriction to -TCP is also mentioned in section 6.1.3.2. of "Requirements for Internet -Hosts - Application and Support" [RFC1123]. - -The most common scenario is for an AXFR client to open a TCP connection -to the AXFR server, send an AXFR query, receive the AXFR response, and -then close the connection. There are variations on this, such as a -query for the zone's SOA resource record first, and so on. Note that -this is documented as a most common scenario. - -The assumption that a TCP connection is dedicated to the single AXFR -session is incorrect, this has led to implementation choices that -prevent either multiple concurrent zone transfers or the use of the -open connection for other queries. - -Being able to have multiple concurrent zone transfers is considered -desirable by operators who have sets of name servers that are -authoritative for a common set of zones. It would be desirable -if the name server implementations did not have to wait for one -zone to transfer before the next could begin. The desire here is to -tighten the specification, not a change, but adding words to the -unclear areas, to define what is needed to permit two servers to -share a TCP connection among concurrent AXFR sessions. The challenge -is to design this in a way that can fall back to the old behavior if -either the AXFR client or AXFR server is incapable of performing -multiple concurrent AXFR sessions. - -With the addition of EDNS0 and applications which require many -small zones such as in web hosting and some ENUM scenarios, AXFR -sessions on UDP would now be possible and seem desirable. However, -there are still some aspects of the AXFR session that are not easily -translated to UDP. This document leaves AXFR over UDP undefined. - -4.1 TCP - -In the original definition there is an implicit assumption (probably -unintentional) that a TCP connection is used for one and only one -AXFR session. This is evidenced in no requirement to copy neither -the Query Section nor the message ID in responses, no explicit -ordering information within the AXFR response messages and the lack -of an explicit notice indicating that a zone transfer continues in the -next message. - -The guidance given here is intended to enable better performance of -the AXFR exchange as well as guidelines on interactions with older -software. Better performance includes being able to multiplex DNS -message exchanges including zone transfer sessions. Guidelines for -interacting with older software are generally applicable to new AXFR -clients. In the reverse situation, older AXFR client and newer AXFR -server ought to induce the server to operate within the specification -for an older server. - -4.1.1 AXFR client TCP - -An AXFR client MAY request a connection to an AXFR server for any -reason. An AXFR client SHOULD close the connection when there is -no apparent need to use the connection for some time period. The -AXFR server ought not have to maintain idle connections, the burden -of connection closure ought to be on the client. Apparent need for -the connection is a judgment for the AXFR client and the DNS -client. If the connection is used for multiple sessions, or if it is -known sessions will be coming or if there is other query/response -traffic anticipated or currently on the open connection, then there -is "apparent need." - -An AXFR client MAY cancel delivery of a zone only by closing the -connection. However, this action will also cancel all other outstanding -activity using the connection. There is no other mechanism by which -an AXFR response can be cancelled. - -When a TCP connection is closed remotely (relative to the client), -whether by the AXFR server or due to a network event, the AXFR client -MUST cancel all outstanding sessions and non-AXFR transactions. -Recovery from this situation is not straightforward. If the disruption -was a spurious event, attempting to restart the connection would be -proper. If the disruption was caused by a medium or long term -disruption, the AXFR client would be wise to not spend too many -resources trying to rebuild the connection. Finally, if the connection -was dropped because of a policy at the AXFR server (as can be the case -with older AXFR servers), the AXFR client would be wise to not retry -the connection. Unfortunately, knowing which of the three cases above -(momentary disruption, failure, policy) applies is not possible with -certainty, and can only be assessed by heuristics. - -An AXFR client MAY use an already opened TCP connection to start an -AXFR session. Using an existing open connection is RECOMMENDED over -opening a new connection. (Non-AXFR session traffic can also use an -open connection.) If in doing so the AXFR client realizes that -the responses cannot be properly differentiated (lack of matching -query IDs for example) or the connection is terminated for a remote -reason, then the AXFR client SHOULD NOT attempt to reuse an open -connection with the specific AXFR server until the AXFR server is -updated (which is of course, not an event captured in the DNS -protocol). - -4.1.2 AXFR server TCP - -An AXFR server MUST be able to handle multiple AXFR sessions on a -single TCP connection, as well as handle other query/response -transactions. - -If a TCP connection is closed remotely, the AXFR server MUST cancel -all AXFR sessions in place. No retry activity is necessary; that is -initiated by the AXFR client. - -Local policy MAY dictate that a TCP connection is to be closed. Such -an action SHOULD be in reaction to limits such as those placed on -the number of outstanding open connections. Closing a connection in -response to a suspected security event SHOULD be done only in extreme -cases, when the server is certain the action is warranted. An -isolated request for a zone not on the AXFR server SHOULD receive -a response with the appropriate return code and not see the connection -broken. - -4.2 UDP - -AXFR sessions over UDP transport are not defined. - -5 Authorization - -A zone administrator has the option to restrict AXFR access to a zone. -This was not envisioned in the original design of the DNS but has -emerged as a requirement as the DNS has evolved. Restrictions on AXFR -could be for various reasons including a desire (or in some instances, -having a legal requirement) to keep the bulk version of the zone -concealed or to prevent the servers from handling the load incurred in -serving AXFR. All reasons are arguable, but the fact remains that -there is a requirement to provide mechanisms to restrict AXFR. - -A DNS implementation SHOULD provide means to restrict AXFR sessions to -specific clients. - -An implementation SHOULD allow access to be granted to Internet -Protocol addresses and ranges, regardless of whether a source address -could be spoofed. Combining this with techniques such as Virtual -Private Networks (VPN) [RFC2764] or Virtual LANs has proven to be -effective. - -A general purpose implementation is RECOMMENDED to implement access -controls based upon "Secret Key Transaction Authentication for DNS" -[RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" -[RFC2931]. - -A general purpose implementation SHOULD allow access to be open to -all AXFR requests. I.e., an operator ought to be able to allow any -AXFR query to be granted. - -A general purpose implementation SHOULD NOT have a default policy -for AXFR requests to be "open to all." For example, a default could -be to restrict transfers to addresses selected by the DNS -administrator(s) for zones on the server. - -6 Zone Integrity - -An AXFR client MUST ensure that only a successfully transferred -copy of the zone data can be used to serve this zone. Previous -description and implementation practice have introduced a two-stage -model of the whole zone synchronization procedure: Upon a trigger -event (e.g., polling of SOA resource record detects change in the -SOA serial number, or via DNS NOTIFY [RFC1996]), the AXFR session -is initiated, whereby the zone data are saved in a zone file or -data base (this latter step is necessary anyway to ensure proper -restart of the server); upon successful completion of the AXFR -operation and some sanity checks, this data set is 'loaded' and -made available for serving the zone in an atomic operation, and -flagged 'valid' for use during the next restart of the DNS server; -if any error is detected, this data set MUST be deleted, and the -AXFR client MUST continue to serve the previous version of the zone, -if it did before. The externally visible behavior of an AXFR client -implementation MUST be equivalent to that of this two-stage model. - -If a server rejects data contained in an AXFR session, the server -SHOULD remember the serial number and MAY attempt to retrieve the -same zone version again. The reason the same retrieval could make -sense is that the reason for the rejection could be rooted in an -implementation detail of one AXFR server used for the zone and not -in another AXFR server used for the zone. - -Ensuring that an AXFR client does not accept a forged copy of a zone is -important to the security of a zone. If a zone operator has the -opportunity, protection can be afforded via dedicated links, physical -or virtual via a VPN among the authoritative servers. But there are -instances in which zone operators have no choice but to run AXFR -sessions over the global public Internet. - -Besides best attempts at securing TCP connections, DNS implementations -SHOULD provide means to make use of "Secret Key Transaction -Authentication for DNS" [RFC2845] and/or "DNS Request and Transaction -Signatures ( SIG(0)s )" [RFC2931] to allow AXFR clients to verify the -contents. These techniques MAY also be used for authorization. - -7 Backwards Compatibility - -Describing backwards compatibility is difficult because of the lack of -specifics in the original definition. In this section some hints at -building in backwards compatibility are given, mostly repeated from the -earlier sections. - -Backwards compatibility is not necessary, but the greater the extent of -an implementation's compatibility the greater it's interoperability. -For turnkey implementations this is not usually a concern. For general -purpose implementations this takes on varying levels of importance -depending on the implementer's desire to maintain interoperability. - -It is unfortunate that a need to fall back to older behavior cannot be -discovered, hence needs to be noted in a configuration file. An -implementation SHOULD, in it's documentation, encourage operators to -periodically review AXFR clients and servers it has made notes about as -old software periodically gets updated. - -7.1 Server - -An AXFR server has the luxury of being able to react to an AXFR -client's abilities with the exception of knowing if the client can -accept multiple resource records per AXFR response message. The -knowledge that a client is so restricted apparently cannot be -discovered, hence it has to be set by configuration. - -An implementation of an AXFR server MAY permit configuring, on a per -AXFR client basis, a need to revert to single resource record per -message; in that case, the default SHOULD be to use multiple records - -7.2 Client - -An AXFR client has the opportunity to try other features (i.e., those -not defined by this document) when querying an AXFR server. - -Attempting to issue multiple DNS queries over a TCP transport for an -AXFR session SHOULD be aborted if it interrupts the original request, -and SHOULD take into consideration whether the AXFR server intends to -close the connection immediately upon completion of the original -(connection-causing) zone transfer. - -8 Security Considerations - -Concerns regarding authorization, traffic flooding, and message -integrity are mentioned in "Authorization" (section 5), "TCP" (section -4.2) and "Zone Integrity" (section 6). - -9 IANA Considerations - -No new registries or new registrations are included in this document. - -10 Internationalization Considerations - -The AXFR protocol is transparent to the parts of DNS zone content that -can possibly be subject to Internationalization considerations. -It is assumed that for DNS labels and domain names, the issue has been -solved via "Internationalizing Domain Names in Applications (IDNA)" -[RFC3490]. - - -11 Acknowledgements - -Earlier editions of this document have been edited by Andreas -Gustafsson. In his latest version, this acknowledgement appeared. - -"Many people have contributed input and commentary to earlier versions -of this document, including but not limited to Bob Halley, Dan -Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz, -Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam Trenholme, -and Brian Wellington." - -Comments since the -05 version have come from these individuals: -Alfred Hoenes, Mark Andrews, Paul Vixie, Wouter Wijngaards, Iain -Calder, Tony Finch, Ian Jackson, Andreas Gustafsson, Brian Wellington, -and other participants of the DNSEXT working group. - -12 References - -All references prefixed by "RFC" can be obtained from the RFC Editor -web site at the URLs: http://rfc-editor.org/rfc.html -or http://rfc-editor.org/rfcsearch.html ; -information regarding this organization can be found at the following -URL: http://rfc-editor.org/ - -12.1 Normative - -[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, - September 1981. -[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August - 1980. -[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. -[RFC1123] Braden, R., "Requirements for Internet Hosts - Application - and Support", STD 3, RFC 1123, October 1989. -[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. -[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", RFC 1996, August 1996. -[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC - 2136, April 1997. -[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS - Specification", RFC 2181, July 1997. -[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. -[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, - August 1999. -[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. -[RFC5395] Eastlake 3rd, "Domain Name System (DNS) IANA Considerations", - BCP 42, RFC 5395, November 2008. -[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. -[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures - ( SIG(0)s )", RFC 2931, September 2000. -[RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 2002. -[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record - (RR) Types", RFC 3597, September 2003. -[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", RFC 4033, - March 2005. -[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. -[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 -[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. -[RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message Authentication - Code, Secure Hash Algorithm) TSIG Algorithm Identifiers", - RFC 4635, August 2006. -[DNSFLGS] http://www.iana.org/assignments/dns-header-flags -[DNSVALS] http://www.iana.org/assignments/dns-parameters - -12.2 Informative - -[BCP14] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. -[RFC1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700, - October 1994. -[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. - Malis, "A Framework for IP Based Virtual Private Networks", - RFC 2764, February 2000. -[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", RFC - 3490, March 2003. -[DRAFT1] Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY and - RRSIG Resource Records for DNSSEC", - draft-ietf-dnsext-dnssec-rsasha256-12, work in progress. -[DRAFT2] Weiler, S., and D. Blacka, "Clarifications and Implementation - Notes for DNSSECbis", - draft-ietf-dnsext-dnssec-bis-updates-08, work in progress. - -13 Editor's Address - -Edward Lewis -46000 Center Oak Plaza -Sterling, VA, 22033, US -+1-571-434-5468 -ed.lewis@neustar.biz diff --git a/doc/draft/draft-ietf-dnsext-dnsproxy-05.txt b/doc/draft/draft-ietf-dnsext-dnsproxy-05.txt deleted file mode 100644 index c5858c00ad7..00000000000 --- a/doc/draft/draft-ietf-dnsext-dnsproxy-05.txt +++ /dev/null @@ -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, - . - - [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on - Broadband Routers and Firewalls", September 2008, - . - - -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] - diff --git a/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt b/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt deleted file mode 100644 index 87bce00b5c0..00000000000 --- a/doc/draft/draft-ietf-dnsext-forgery-resilience-02.txt +++ /dev/null @@ -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 , -Bert Hubert diff --git a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt b/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt deleted file mode 100644 index 8f84fd4db24..00000000000 --- a/doc/draft/draft-ietf-dnsext-rfc2671bis-edns0-01.txt +++ /dev/null @@ -1,480 +0,0 @@ - - - - - - -DNSEXT Working Group Paul Vixie, ISC -INTERNET-DRAFT - 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] - \ No newline at end of file diff --git a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt b/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt deleted file mode 100644 index 72d38aa267a..00000000000 --- a/doc/draft/draft-ietf-dnsext-tsig-md5-deprecated-03.txt +++ /dev/null @@ -1,336 +0,0 @@ - - - -DNSext Working Group F. Dupont -Internet-Draft ISC -Updates: 2845,2930,4635 May 8, 2009 -(if approved) -Intended status: Standards Track -Expires: November 9, 2009 - - - Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records - draft-ietf-dnsext-tsig-md5-deprecated-03.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - from IETF Documents or IETF Contributions published or made publicly - available before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the IETF - Trust the right to allow modifications of such material outside the - IETF Standards Process. Without obtaining an adequate license from - the person(s) controlling the copyright in such materials, this - document may not be modified outside the IETF Standards Process, and - derivative works of it may not be created outside the IETF Standards - Process, except to format it for publication as an RFC or to - translate it into languages other than English. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 9, 2009. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - - -Dupont Expires November 9, 2009 [Page 1] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. - -Abstract - - The main purpose of this document is to deprecate the use of HMAC-MD5 - as an algorithm for the TSIG (secret key transaction authentication) - resource record in the DNS (domain name system), and the use of MD5 - in TKEY (secret key establishment for DNS). - - -1. Introduction - - The secret key transaction authentication for DNS (TSIG, [RFC2845]) - was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm. - When the MD5 [RFC1321] security came to be considered lower than - expected, [RFC4635] standardized new TSIG algorithms based on SHA - [RFC3174][RFC3874][RFC4634] digests. - - But [RFC4635] did not deprecate the HMAC-MD5 algorithm. This - document is targeted to complete the process, in detail: - 1. Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm - name registry managed by the IANA under the IETF Review Policy - [RFC5226] - 2. Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for - implementations - 3. Provide a keying material derivation for the secret key - establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman - exchange with SHA256 [RFC4634] in place of MD5 [RFC1321] - 4. Finally recommend the use of HMAC-SHA256. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - -2. Implementation Requirements - - The table of section 3 of [RFC4635] is replaced by: - - - - - - - - - -Dupont Expires November 9, 2009 [Page 2] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - +-------------------+--------------------------+ - | Requirement Level | Algorithm Name | - +-------------------+--------------------------+ - | Optional | HMAC-MD5.SIG-ALG.REG.INT | - | Optional | gss-tsig | - | Mandatory | hmac-sha1 | - | Optional | hmac-sha224 | - | Mandatory | hmac-sha256 | - | Optional | hmac-sha384 | - | Optional | hmac-sha512 | - +-------------------+--------------------------+ - - Implementations that support TSIG MUST also implement HMAC-SHA1 and - HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level) - and MAY implement GSS-TSIG and the other algorithms listed above - (i.e., algorithms at a "not Mandatory" requirement level). - - -3. TKEY keying material derivation - - When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying - material is derived from the shared secret and TKEY resource record - data using MD5 [RFC1321] at the end of section 4.1 page 9. - - This is amended into: - - keying material = - XOR ( DH value, SHA256 ( query data | DH value ) | - SHA256 ( server data | DH value ) ) - - using the same conventions. - - -4. IANA Consideration - - This document extends the "TSIG Algorithm Names - per [] and - [RFC2845]" located at - http://www.iana.org/assignments/tsig-algorithm-names by adding a new - column to the registry "Compliance Requirement". - - The registry should contain the following: - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 3] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - - +--------------------------+------------------------+-------------+ - | Algorithm Name | Compliance Requirement | Reference | - +--------------------------+------------------------+-------------+ - | gss-tsig | Optional | [RFC3645] | - | HMAC-MD5.SIG-ALG.REG.INT | Optional | [][RFC2845] | - | hmac-sha1 | Mandatory | [RFC4635] | - | hmac-sha224 | Optional | [RFC4635] | - | hmac-sha256 | Mandatory | [RFC4635] | - | hmac-sha384 | Optional | [RFC4635] | - | hmac-sha512 | Optional | [RFC4635] | - +--------------------------+------------------------+-------------+ - - where [] is this document. - - -5. Availability Considerations - - MD5 is no longer universally available and its use may lead to - increasing operation issues. SHA1 is likely to suffer from the same - kind of problem. In summary MD5 has reached end-of-life and SHA1 - will likely follow in the near term. - - According to [RFC4635], implementations which support TSIG are - REQUIRED to implement HMAC-SHA256. - - -6. Security Considerations - - This document does not assume anything about the cryptographic - security of different hash algorithms. Its purpose is a better - availability of some security mechanisms in a predictable time frame. - - Requirement levels are adjusted for TSIG and related specifications - (i.e., TKEY): - The support of HMAC-MD5 is changed from mandatory to optional. - The use of MD5 and HMAC-MD5 is NOT RECOMMENDED. - The use of HMAC-SHA256 is RECOMMENDED. - - -7. Acknowledgments - - Olafur Gudmundsson kindly helped in the procedure to deprecate the - MD5 use in TSIG, i.e., the procedure which led to this memo. Alfred - Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some - improvements. - - -8. References - - - -Dupont Expires November 9, 2009 [Page 4] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - -8.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers", - RFC 4635, August 2006. - -8.2. Informative References - - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - - [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 - (SHA1)", RFC 3174, September 2001. - - [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., - and R. Hall, "Generic Security Service Algorithm for - Secret Key Transaction Authentication for DNS (GSS-TSIG)", - RFC 3645, October 2003. - - [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", - RFC 3874, September 2004. - - [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms - (SHA and HMAC-SHA)", RFC 4634, July 2006. - - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 5226, BCP 26, - May 2008. - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 5] - -Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009 - - -Author's Address - - Francis Dupont - ISC - - Email: Francis.Dupont@fdupont.fr - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Dupont Expires November 9, 2009 [Page 6] - diff --git a/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt b/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt deleted file mode 100644 index 230c0367762..00000000000 --- a/doc/draft/draft-ietf-dnsop-default-local-zones-05.txt +++ /dev/null @@ -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", . - - [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] - diff --git a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt b/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt deleted file mode 100644 index f64e8dd572e..00000000000 --- a/doc/draft/draft-ietf-dnsop-name-server-management-reqs-02.txt +++ /dev/null @@ -1,952 +0,0 @@ - - - -DNSOP W. Hardaker -Internet-Draft Sparta, Inc. -Intended status: Informational February 12, 2009 -Expires: August 16, 2009 - - - Requirements for Management of Name Servers for the DNS - draft-ietf-dnsop-name-server-management-reqs-02.txt - -Status of this Memo - - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 16, 2009. - -Copyright Notice - - Copyright (c) 2009 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. - -Abstract - - Management of name servers for the Domain Name Service (DNS) has - traditionally been done using vendor-specific monitoring, - - - -Hardaker Expires August 16, 2009 [Page 1] - -Internet-Draft Name Server Management Requirements February 2009 - - - configuration and control methods. Although some service monitoring - platforms can test the functionality of the DNS itself there is not a - interoperable way to manage (monitor, control and configure) the - internal aspects of a name server itself. - - This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 - 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5 - 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5 - 2. Management Architecture Requirements . . . . . . . . . . . . . 5 - 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5 - 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5 - 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6 - 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6 - 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6 - 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6 - 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7 - 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7 - 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7 - 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8 - 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8 - 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8 - 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9 - 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9 - 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9 - 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9 - 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9 - 3.2.5. DNS Protocol Authorization Management . . . . . . . . 9 - 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10 - 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10 - 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 - 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11 - 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11 - 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 - 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11 - 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12 - 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13 - 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13 - 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13 - - - -Hardaker Expires August 16, 2009 [Page 2] - -Internet-Draft Name Server Management Requirements February 2009 - - - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 - Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15 - A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16 - A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16 - A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Hardaker Expires August 16, 2009 [Page 3] - -Internet-Draft Name Server Management Requirements February 2009 - - -1. Introduction - - Management of name servers for the Domain Name Service (DNS) - [RFC1034] [RFC1035] has traditionally been done using vendor-specific - monitoring, configuration and control methods. Although some service - monitoring platforms can test the functionality of the DNS itself - there is not a interoperable way to manage (monitor, control and - configure) the internal aspects of a name server itself. - - Previous standardization work within the IETF resulted in the - creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed - to achieve significant implementation and deployment. The perceived - reasons behind the failure for the two MIB modules are further - documented in [RFC3197]. - - This document discusses the requirements of a management system for - DNS name servers. A management solution that is designed to manage - the DNS can use this document as a shopping list of needed features. - - Specifically out of scope for this document are requirements - associated with management of stub resolvers. It is not the intent - of this document to document stub resolver requirements, although - some of the requirements listed are applicable to stub resolvers as - well. - - Also out of scope for this document is management of the host or - other components of the host upon which the name server software is - running. This document only discusses requirements for managing the - name server component of a system. - - The task of creating a management system for managing DNS servers is - not expected to be a small one. It is likely that components of the - solution will need to be designed in parts over time and these - requirements take this into consideration. In particular, - Section 5.1 discusses the need for future extensibility of the base - management solution. This document is intended to be a road-map - towards a desired outcome and is not intended to define an "all-or- - nothing" system. Successful interoperable management of name servers - even in part is expected to be beneficial to network operators - compared to the entirely custom solutions that are used at the time - of this writing. - -1.1. Requirements notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - -Hardaker Expires August 16, 2009 [Page 4] - -Internet-Draft Name Server Management Requirements February 2009 - - -1.1.1. Terminology - - This document is consistent with the terminology defined in Section 2 - of [RFC4033]. Additional terminology needed for this document is - described below: - - Name Server: When we are discussing servers that don't fall into a - more specific type of server category defined in other documents, - this document will refer to them generically as "name servers". - In particular "name servers" can be considered to be any valid - combination of authoritative, recursive, validating, or security- - aware. The more specific name server labels will be used when - this document refers only to a specific type of server. However, - the term "name server", in this document, will not include stub - resolvers. - -1.1.2. Document Layout and Requirements - - The document is written so that each numbered section will contain - only a single requirement if it contains one at all. Each - requirement will contain needed wording from the terminology - described in Section 1.1. Subsections, however, might exist with - additional related requirements. The document is laid out in this - way so that a specific requirement can be uniquely referred to using - the section number itself and the document version from which it - came. - - -2. Management Architecture Requirements - - This section discusses requirements that reflect the needs of the - expected deployment environments. - -2.1. Expected Deployment Scenarios - - DNS zones vary greatly in the type of content published within them. - Name Servers, too, are deployed with a wide variety of configurations - to support the diversity of the deployed content. It is important - that a management solution trying to meet the criteria specified in - this document consider supporting the largest number of potential - deployment cases as possible. Further deployment scenarios that are - not used as direct examples of specific requirements are listed in - Appendix A. - -2.1.1. Zone Size Constraints - - The management solution MUST support both name servers that are - serving a small number of potentially very large zones (e.g. Top - - - -Hardaker Expires August 16, 2009 [Page 5] - -Internet-Draft Name Server Management Requirements February 2009 - - - Level Domains (TLDs)) as well as name servers that are serving a very - large number of small zones. These scenarios are both commonly seen - deployments. - -2.1.2. Name Server Discovery - - Large enterprise network deployments may contain multiple name - servers operating within the boundaries of the enterprise network. - These name servers may each be serving multiple zones both in and out - of the parent enterprise's zone. Finding and managing large - quantities of name servers would be a useful feature of the resulting - management solution. The management solution MAY support the ability - to discover previously unknown instances of name servers operating - within a deployed network. - -2.1.3. Configuration Data Volatility - - Configuration data is defined as data that relates only to the - configuration of a server and the zones it serves. It specifically - does not include data from the zone contents that is served through - DNS itself. The solution MUST support servers that remain fairly - statically configured over time as well as servers that have numerous - zones being added and removed within an hour. Both of these - scenarios are also commonly seen deployments. - -2.1.4. Protocol Selection - - There are many requirements in this document for many different types - of management operations (see Section 3 for further details). It is - possible that no one protocol will ideally fill all the needs of the - requirements listed in this document and thus multiple protocols - might be needed to produce a completely functional management system. - Multiple protocols might be used to create the complete management - solution, but the number of protocols used SHOULD be reduced to a - reasonable minimum number. - -2.1.5. Common Data Model - - Defining a standardized protocol (or set of protocols) to use for - managing name servers would be a step forward in achieving an - interoperable management solution. However, just defining a protocol - to use by itself would not achieve the complete end goal of a - complete interoperable management solution. Devices also need to - represent their internal management interface using a common - management data model. The solution MUST create a common data model - that management stations can make use of when sending or collecting - data from a managed device so it can successfully manage equipment - from vendors as if they were generic DNS servers. This common data - - - -Hardaker Expires August 16, 2009 [Page 6] - -Internet-Draft Name Server Management Requirements February 2009 - - - model is needed for of the operations discussion in Section 3. Note - that this does not preclude the fact that name server vendors might - provide additional management infrastructure beyond a base management - specification, as discussed further in Section 5.1. - -2.1.6. Operational Impact - - It is impossible to add new features to an existing server (such as - the inclusion of a management infrastructure) and not impact the - existing service and/or server in some fashion. At a minimum, for - example, more memory, disk and/or CPU resources will be required to - implement a new management system. However, the impact to the - existing DNS service MUST be minimized since the DNS service itself - is still the primary service to be offered by the modified name - server. - -2.2. Name Server Types - - There are multiple ways in which name servers can be deployed. Name - servers can take on any of the following roles: - - o Master Servers - - o Slave Servers - - o Recursive Servers - - The management solution SHOULD support all of these types of name - servers as they are all equally important. Note that "Recursive - Servers" can be further broken down by the security sub-roles they - might implement, as defined in section 2 of [RFC4033]. These sub- - roles are also important to support within any management solution. - - As stated earlier, the management of stub resolvers is considered out - of scope for this documents. - - -3. Management Operation Types - - Management operations can traditionally be broken into four - categories: - - o Control - - o Configuration - - o Health and Monitoring - - - - -Hardaker Expires August 16, 2009 [Page 7] - -Internet-Draft Name Server Management Requirements February 2009 - - - o Alarms and Events - - This section discusses requirements for each of these four management - types in detail. - -3.1. Control Requirements - - The management solution MUST be capable of performing basic service - control operations. - -3.1.1. Needed Control Operations - - These operations SHOULD include, at a minimum, the following - operations: - - o Starting the name server - - o Reloading the service configuration - - o Reloading zone data - - o Restarting the name server - - o Stopping the name server - - Note that no restriction is placed on how the management system - implements these operations. In particular, at least "starting the - name server" will require a minimal management system component to - exist independently of the name server itself. - -3.1.2. Asynchronous Status Notifications - - Some control operations might take a long time to complete. As an - example, some name servers take a long time to perform reloads of - large zones. Because of these timing issues, the management solution - SHOULD take this into consideration and offer a mechanism to ease the - burden associated with awaiting the status of a long-running command. - This could, for example, result in the use of asynchronous - notifications for returning the status of a long-running task or it - might require the management station to poll for the status of a - given task using monitoring commands. These and other potential - solutions need to be evaluated carefully to select one that balances - the result delivery needs with the perceived implementation costs. - - Also, see the related discussion in Section 3.4 on notification - messages for supporting delivery of alarm and event messages. - - - - - -Hardaker Expires August 16, 2009 [Page 8] - -Internet-Draft Name Server Management Requirements February 2009 - - -3.2. Configuration Requirements - - Many features of name servers need to be configured before the server - can be considered functional. The management solution MUST be able - to provide name servers with configuration data. The most important - data to be configured, for example, is the served zone data itself. - -3.2.1. Served Zone Modification - - The ability to add, modify and delete zones being served by name - servers is needed. Although there are already solutions for zone - content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007], - AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that - might be used as part of the final management solution, the - management system SHOULD still be able to natively create a new zone - (with enough minimal data to allow the other mechanisms to function - as well) as well as delete a zone. This might be, for example, a - management operation that at least allows for the creation of the - initial SOA record for a new zone as that's the minimum amount of - zone data needed for the other operations to function. - -3.2.2. Trust Anchor Management - - The solution SHOULD support the ability to add, modify and delete - trust anchors that are used by DNS Security (DNSSEC) [RFC4033] - [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust - anchors might be configured using the data from the DNSKEY Resource - Records (RRs) themselves or by using Delegation Signer (DS) - fingerprints. - -3.2.3. Security Expectations - - DNSSEC Validating resolvers need to make policy decisions about the - requests being processed. For example, they need to be configured - with a list of zones expected to be secured by DNSSEC. The - management solution SHOULD be able to add, modify and delete - attributes of DNSSEC security policies. - -3.2.4. TSIG Key Management - - TSIG [RFC2845] allows transaction level authentication of DNS - traffic. The management solution SHOULD be able to add, modify and - delete TSIG keys known to the name server. - -3.2.5. DNS Protocol Authorization Management - - The management solution SHOULD have the ability to add, modify and - delete authorization settings for the DNS protocols itself. Do not - - - -Hardaker Expires August 16, 2009 [Page 9] - -Internet-Draft Name Server Management Requirements February 2009 - - - confuse this with the ability to manage the authorization associated - with the management protocol itself, which is discussed later in - Section 4.4. There are a number of authorization settings that are - used by a name server. Example authorization settings that the - solution might need to cover are: - - o Access to operations on zone data (e.g. DDNS) - - o Access to certain zone data from certain sources (e.g. from - particular network subnets) - - o Access to specific DNS protocol services (e.g. recursive service) - - Note: the above list is expected to be used as a collection of - examples and is not a complete list of needed authorization - protections. - -3.3. Monitoring Requirements - - Monitoring is the process of collecting aspects of the internal state - of a name server at a given moment in time. The solution MUST be - able to monitor the health of a name server to determine its - operational status, load and other internal attributes. Example - management tasks that the solution might need to cover are: - - o Number of requests sent, responses sent, average response latency - and other performance counters - - o Server status (e.g. "serving data", "starting up", "shutting - down", ...) - - o Access control violations - - o List of zones being served - - o Detailed statistics about clients interacting with the name server - (e.g. top 10 clients requesting data). - - Note: the above list is expected to be used as a collection of - examples and is not a complete list of needed monitoring operations. - In particular, some monitoring statistics are expected to be - computationally or resource expensive and are considered to be "nice - to haves" as opposed to "necessary to have". - -3.4. Alarm and Event Requirements - - Events occurring at the name server that trigger alarm notifications - can quickly inform a management station about critical issues. A - - - -Hardaker Expires August 16, 2009 [Page 10] - -Internet-Draft Name Server Management Requirements February 2009 - - - management solution SHOULD include support for delivery of alarm - conditions. - - Example alarm conditions might include: - - o The server's status is changing. (e.g it is starting up, reloading - configuration, restarting or shutting down) - - o A needed resource (e.g. memory or disk space) is exhausted or - nearing exhaustion - - o An authorization violation was detected - - o The server has not received any data traffic (e.g. DNS requests - or NOTIFYs) recently (AKA the "lonely warning"). This condition - might indicate a problem with its deployment. - - -4. Security Requirements - - The management solution will need to be appropriately secured against - attacks on the management infrastructure. - -4.1. Authentication - - The solution MUST support mutual authentication. The management - client needs to be assured that the management operations are being - transferred to and from the correct name server. The managed name - server needs to authenticate the system that is accessing the - management infrastructure within itself. - -4.2. Integrity Protection - - Management operations MUST be protected from modification while in - transit from the management client to the server. - -4.3. Confidentiality - - The management solution MUST support message confidentiality. The - potential transfer of sensitive configuration is expected (such as - TSIG keys or security policies). The solution does not, however, - necessarily need to provide confidentiality to data that would - normally be carried without confidentiality by the DNS system itself. - -4.4. Authorization - - The solution SHOULD be capable of providing a fine-grained - authorization model for any management protocols it introduces to the - - - -Hardaker Expires August 16, 2009 [Page 11] - -Internet-Draft Name Server Management Requirements February 2009 - - - completed system. This authorization differs from the authorization - previously discussed in Section 3.2.5 in that this requirement is - concerned solely with authorization of the management system itself. - - There are a number of authorization settings that might be used by a - managed system to determine whether the managing entity has - authorization to perform the given management task. Example - authorization settings that the solution might need to cover are: - - o Access to the configuration that specifies which zones are to be - served - - o Access to the management system infrastructure - - o Access to other control operations - - o Access to other configuration operations - - o Access to monitoring operations - - Note: the above list is expected to be used as a collection of - examples and is not a complete list of needed authorization - protections. - -4.5. Solution Impacts on Security - - The solution MUST minimize the security risks introduced to the - complete name server system. It is impossible to add new - infrastructure to a server and not impact the security in some - fashion as the introduction of a management protocol alone will - provide a new avenue for potential attack. Although the added - management benefits will be worth the increased risks, the solution - still needs to minimize this impact as much as possible. - - -5. Other Requirements - -5.1. Extensibility - - The management solution is expected to change and expand over time as - lessons are learned and new DNS features are deployed. Thus, the - solution MUST be flexible and be able to accommodate new future - management operations. The solution might, for example, make use of - protocol versioning or capability description exchanges to ensure - that management stations and name servers that weren't written to the - same specification version can still interoperate to the best of - their combined ability. - - - - -Hardaker Expires August 16, 2009 [Page 12] - -Internet-Draft Name Server Management Requirements February 2009 - - -5.1.1. Vendor Extensions - - It MUST be possible for vendors to extend the standardized management - model with vendor-specific extensions to support additional features - offered by their products. - -5.1.2. Extension Identification - - It MUST be possible for a management station to understand which - parts of returned data are specific to a given vendor or other - standardized extension. The data returned needs to be appropriately - marked through the use of name spaces or similar mechanisms to ensure - that the base management model data can be logically separated from - extension data without needing to understand the extension data - itself. - -5.1.3. Name-Space Collision Protection - - It MUST be possible to protect against multiple extensions - conflicting with each other. The use of name-space protection - mechanisms for communicated management variables is common practice - to protect against problems. Name-space identification techniques - also frequently solve the "Extension Identification" requirement - discussed in Section 5.1.2 as well. - - -6. Security Considerations - - Any management protocol that meets the criteria discussed in this - document needs to support the criteria discussed in Section 4 in - order to protect the management infrastructure itself. The DNS is a - core Internet service and management traffic that protects it could - be the target of attacks designed to subvert that service. Because - the management infrastructure will be adding additional interfaces to - that service, it is critical that the management infrastructure - support adequate protections against network attacks. - - -7. IANA Considerations - - No action is required from IANA for this document. - - -8. Document History - - A requirement gathering discussion was held at the December 2007 IETF - meeting in Vancouver, BC, Canada and a follow up meeting was held at - the March 2008 IETF meeting in Philadelphia. This document is a - - - -Hardaker Expires August 16, 2009 [Page 13] - -Internet-Draft Name Server Management Requirements February 2009 - - - compilation of the results of those discussions as well as - discussions on the DCOMA mailing list. - - -9. Acknowledgments - - This draft is the result of discussions within the DCOMA design team - chaired by Jaap Akkerhuis. This team consisted of a large number of - people all of whom provided valuable insight and input into the - discussions surrounding name server management. The text of this - document was written from notes taken during meetings as well as from - contributions sent to the DCOMA mailing list. This work documents - the consensus of the DCOMA design team. - - In particular, the following team members contributed significantly - to the text in the document: - - Stephane Bortzmeyer - - Stephen Morris - - Phil Regnauld - - Further editing contributions and wording suggestions were made by: - Alfred Hoenes. - - -10. References - -10.1. Normative References - - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. - - [RFC1035] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, - "Dynamic Updates in the Domain Name System (DNS UPDATE)", - RFC 2136, April 1997. - - [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. - - - -Hardaker Expires August 16, 2009 [Page 14] - -Internet-Draft Name Server Management Requirements February 2009 - - - Wellington, "Secret Key Transaction Authentication for DNS - (TSIG)", RFC 2845, May 2000. - - [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic - Update", RFC 3007, November 2000. - - [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "DNS Security Introduction and Requirements", - RFC 4033, March 2005. - - [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Resource Records for the DNS Security Extensions", - RFC 4034, March 2005. - - [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. - Rose, "Protocol Modifications for the DNS Security - Extensions", RFC 4035, March 2005. - - [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer - (DS) Resource Records (RRs)", RFC 4509, May 2006. - - [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC) - Trust Anchors", RFC 5011, September 2007. - - [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS - Security (DNSSEC) Hashed Authenticated Denial of - Existence", RFC 5155, March 2008. - -10.2. Informative References - - [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions", - RFC 1611, May 1994. - - [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions", - RFC 1612, May 1994. - - [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection - and Operation of Secondary DNS Servers", BCP 16, RFC 2182, - July 1997. - - [RFC3197] Austein, R., "Applicability Statement for DNS MIB - Extensions", RFC 3197, November 2001. - - -Appendix A. Deployment Scenarios - - This appendix documents some additional deployment scenarios that - have been traditionally difficult to manage. They are provided as - - - -Hardaker Expires August 16, 2009 [Page 15] - -Internet-Draft Name Server Management Requirements February 2009 - - - guidance to protocol developers as data points of real-world name - server management problems. - -A.1. Non-Standard Zones - - If an organization uses non-standard zones (for example a purely- - local TLD), synchronizing all the name servers for these zones is - usually a time-consuming task. It is made worse when two - organizations with conflicting zones merge. This situation is not a - recommended deployment scenario (and is even heavily discouraged) but - it is, unfortunately, seen in the wild. - - It is typically implemented using "forwarding" zones. But there is - no way to ensure automatically that all the resolvers have the same - set of zones to forward at any given time. New zones might be added - to a local forwarding recursive server, for example, without - modifying the rest of the deployed forwarding servers. It is hoped - that a management solution which could handle the configuration of - zone forwarding would finally allow management of servers deployed in - this fashion. - -A.2. Redundancy Sharing - - For reliability reasons it is recommended that zone operators follow - the guidelines documented in [RFC2182] which recommends that multiple - name servers be configured for each zone and that the name servers - are separated both physically and via connectivity routes. A common - solution is to establish DNS-serving partnerships: "I'll host your - zones and you'll host mine". Both entities benefit from increased - DNS reliability via the wider service distribution. This frequently - occurs between cooperating but otherwise unrelated entities (such as - between two distinct companies) as well as between affiliated - organizations (such as between branch offices within a single - company). - - The configuration of these relationships are currently required to be - manually configured and maintained. Changes to the list of zones - that are cross-hosted are manually negotiated between the cooperating - network administrators and configured by hand. A management protocol - with the ability to provide selective authorization, as discussed in - Section 4.4, would solve many of the management difficulties between - cooperating organizations. - -A.3. DNSSEC Management - - There are many different DNSSEC deployment strategies that may be - used for mission-critical zones. The following list describes some - example deployment scenarios that might warrant different management - - - -Hardaker Expires August 16, 2009 [Page 16] - -Internet-Draft Name Server Management Requirements February 2009 - - - strategies. - - All contents and DNSSEC keying information controlled and operated - by a single organization - - Zone contents controlled and operated by one organization, all - DNSSEC keying information controlled and operated by a second - organization. - - Zone contents controlled and operated by one organization, zone - signing keys (ZSKs) controlled and operated by a second - organization, and key signing keys (KSKs) controlled and operated - by a third organization. - - Although this list is not exhaustive in the potential ways that zone - data can be divided up, it should be sufficient to illustrate the - potential ways in which zone data can be controlled by multiple - entities. - - The end result of all of these strategies, however, will be the same: - a live zone containing DNSSEC related resource records. Many of the - above strategies are merely different ways of preparing a zone for - serving. A management solution that includes support for managing - DNSSEC zone data may wish to take into account these potential - management scenarios. - - -Author's Address - - Wes Hardaker - Sparta, Inc. - P.O. Box 382 - Davis, CA 95617 - US - - Phone: +1 530 792 1913 - Email: ietf@hardakers.net - - - - - - - - - - - - - - -Hardaker Expires August 16, 2009 [Page 17] -