+++ /dev/null
-DNS Extensions working group V.Dolmatov, Ed.
-Internet-Draft Cryptocom Ltd.
-Intended status: Standards Track April 8, 2009
-Expires: December 31, 2009
-
-
- Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
- for DNSSEC
- draft-dolmatov-dnsext-dnssec-gost-00
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on 31 December 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-Abstract
-
- This document describes how to produce GOST signature and hash algorithms
- DNSKEY and RRSIG resource records for use in the Domain Name System
- Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
- 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . .
- 2.1. Using a public key with existing cryptographic libraries. .
- 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . .
- 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . .
- 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . .
- 5. NSEC3 Resource Records . . . . . . . . . . . . . . . . . . . .
- 6. Deployment Considerations . . . . . . . . . . . . . . . . . . .
- 6.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . .
- 6.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . .
- 6.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . .
- 7. Implementation Considerations . . . . . . . . . . . . . . . . .
- 7.1. Support for GOST signatures . . . . . . . . . . . . . . . .
- 7.2. Support for NSEC3 Denial of Existence . . . . . . . . . . .
- 7.2.1. NSEC3 in Authoritative servers . . . . . . . . . . . .
- 7.2.2. NSEC3 in Validators . . . . . . . . . . . . . . . . . .
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . .
- 10.1. Normative References . . . . . . . . . . . . . . . . . . .
- 10.2. Informative References . . . . . . . . . . . . . . . . . .
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical distributed
- database for Internet Naming. The DNS has been extended to use
- cryptographic keys and digital signatures for the verification of the
- authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034
- [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
- Extensions, called DNSSEC.
-
- RFC 4034 describes how to store DNSKEY and RRSIG resource records,
- and specifies a list of cryptographic algorithms to use. This
- document extends that list with the signature and hash algorithms
- GOST [GOST3410, GOST3411],
- and specifies how to store DNSKEY data and how to produce
- RRSIG resource records with these hash algorithms.
-
- Familiarity with DNSSEC and GOST signature and hash
- algorithms is assumed in this document.
-
- The term "GOST" is not officially defined, but is usually used to
- refer to the collection of the Russian cryptographic algorithms
- GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. Since GOST 28147-89
- is not used in DNSSEC, GOST will only refer to GOST R 34.10-2001
- (signatire algorithm) and GOST R 34.11-94 (hash algorithm) in this
- document.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-2. DNSKEY Resource Records
-
- The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
- GOST R 34.10-2001 public keys are stored with the algorithm number {TBA1}.
-
- The public key parameters are those identified by
- id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357].
- The digest parameters for signature are those identified by
- id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
- The wire format of the public key is compatible with RFC 4491 [RFC4491]:
-
- According to [GOSTR341001], a public key is a point on the elliptic
- curve Q = (x,y).
-
- The wire representation of a public key MUST contain 64 octets, where the
- first 32 octets contain the little-endian representation of x and the
- second 32 octets contain the little-endian representation of y. This
- corresponds to the binary representation of (<y>256||<x>256) from
- [GOSTR341001], ch. 5.3.
-
-2.1. Using a public key with existing cryptographic libraries
-
- Existing GOST-aware cryptographic libraries at time of this document
- writing are capable to read GOST public keys via generic X509 API if the
- key is encoded according to RFC 4491 [RFC4491], section 2.3.2.
-
- To make this encoding from the wire format of a GOST public key, prepend
- a key data with the following 37-byte sequence:
-
- 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 0x12
- 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a 0x85 0x03
- 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-
-2.2. GOST DNSKEY RR Example
-
- The following DNSKEY RR stores a DNS zone key for example.com
-
- example.com. 86400 IN DNSKEY 256 3 {TBA1} ( RamuUwTG1r4RUqsgXu/xF6B+Y
- tJLzZEykiZ4C2Fa1gV1pI/8GA
- el2Wm69Cz5h1T9eYAQKFAGwzW
- m4Lke0E26aw== )
-
-3. RRSIG Resource Records
-
- The value of the signature field in the RRSIG RR follows the RFC 4490
- [RFC4490] and is calculated as follows. The values for the RDATA fields
- that precede the signature data are specified in RFC 4034 [RFC4034].
-
- hash = GOSTR3411(data)
-
- where "data" is the wire format data of the resource record set that is
- signed, as specified in RFC 4034 [RFC4034]. Hash MUST be calculated with
- GOST R 34.11-94 parameters identified by
- id-GostR3411-94-CryptoProParamSet [RFC4357].
-
- Signature is calculated from the hash according to the GOST R 34.10-2001
- standard and its wire format is compatible with RFC 4490 [RFC4490].
- Quoting RFC 4490:
-
- "The signature algorithm GOST R 34.10-2001 generates a digital
- signature in the form of two 256-bit numbers, r and s. Its octet
- string representation consists of 64 octets, where the first 32
- octets contain the big-endian representation of s and the second 32
- octets contain the big-endian representation of r."
-
-4. DS Resource Records
-
- GOST R 34.11-94 digest algorithm is denoted in DS RR by the digest type
- {TBA2}. The wire format of a digest value is compatible with RFC 4490
- [RFC4490]. Quoting RFC 4490:
-
- "A 32-byte digest in little-endian representation."
-
- The digest MUST always be calculated with GOST R 34.11-94 parameters
- identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-5. NSEC3 Resource Records
-
- GOST R 34.11-94 digest algorithm is denoted in NSEC3 RR by the digest type
- {TBA2}. The wire format of a digest value is compatible with RFC 4490
- [RFC4490]. Quoting RFC 4490:
-
- "A 32-byte digest in little-endian representation."
-
- The digest MUST always be calculated with GOST R 34.11-94 parameters
- identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-6. Deployment Considerations
-
-6.1. Key Sizes
-
- According to RFC4357 [RFC4357] key size of GOST public keys MUST
- be 512 bits.
-
-6.2. Signature Sizes
-
- According to GOST signature algorithm [GOST3410] size of GOST signature
- is 512 bit.
-
-6.3. Digest Sizes
-
- According to GOST R 34.11-94 [GOST3411] size of GOST digest is 256 bit.
-
-7. Implementation Considerations
-
-7.1. Support for GOST signatures
-
- DNSSEC aware implementations SHOULD be able to support RRSIG and
- DNSKEY resource records created with the GOST algorithms as
- defined in this document.
-
-7.2. Support for NSEC3 Denial of Existence
-
- RFC5155 [RFC5155] defines new algorithm identifiers for existing
- signing algorithms, to indicate that zones signed with these
- algorithm identifiers use NSEC3 instead of NSEC records to provide
- denial of existence. That mechanism was chosen to protect
- implementations predating RFC5155 from encountering resource records
- they could not know about. This document does not define such
- algorithm aliases, and support for NSEC3 denial of existence is
- implicitly signaled with support for one of the algorithms defined in
- this document.
-
-7.2.1. NSEC3 in Authoritative servers
-
- An authoritative server that does not implement NSEC3 MAY still serve
- zones that use GOST with NSEC denial of existence.
-
-7.2.2. NSEC3 in Validators
-
- A DNSSEC validator that implements GOST MUST be able to handle
- both NSEC and NSEC3 [RFC5155] negative answers. If this is not the
- case, the validator MUST treat a zone signed with GOST
- as signed with an unknown algorithm, and thus as insecure.
-
-
-8. IANA Considerations
-
- This document updates the IANA registry "DNS SECURITY ALGORITHM
- NUMBERS -- per [RFC4035] "
- (http://www.iana.org/assignments/dns-sec-alg-numbers). The following
- entries are added to the registry:
- Zone Trans.
- Value Algorithm Mnemonic Signing Sec. References Status
- {TBA1} GOST R 34.10-2001 GOST Y * (this memo) OPTIONAL
-
- This document updates the RFC 4034 [RFC4034] Digest Types assignment
- (RFC 4034, section A.2):
-
- Value Algorithm Status
- {TBA2} GOST R 34.11-94 OPTIONAL
-
-9. Acknowledgments
-
- This document is a minor extension to RFC 4034 [RFC4034]. Also, we
- try to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509]
- and RFC 4357 [RFC4357] for consistency. The authors of and
- contributors to these documents are gratefully acknowledged for
- their hard work.
-
- The following people provided additional feedback and text: Dmitry
- Burkov, Jaap Akkerhuis, Jelte Jansen and Wouter Wijngaards.
-
-
-10. References
-
-10.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
- Name System (DNS)", RFC 3110, May 2001.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [GOST3410] "Information technology. Cryptographic data security.
- Signature and verification processes of [electronic]
- digital signature.", GOST R 34.10-2001, Gosudarstvennyi
- Standard of Russian Federation, Government Committee of
- the Russia for Standards, 2001. (In Russian)
-
- [GOST3411] "Information technology. Cryptographic Data Security.
- Hashing function.", GOST R 34.11-94, Gosudarstvennyi
- Standard of Russian Federation, Government Committee of
- the Russia for Standards, 1994. (In Russian)
-
- [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional
- Cryptographic Algorithms for Use with GOST 28147-89,
- GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
- Algorithms", RFC 4357, January 2006.
-
- [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89,
- GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001
- Algorithms with Cryptographic Message Syntax (CMS)",
- RFC 4490, May 2006.
-
- [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST
- R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
- Algorithms with the Internet X.509 Public Key
- Infrastructure Certificate and CRL Profile", RFC 4491,
- May 2006.
-
-
-
-10.2. Informative References
-
- [NIST800-57]
- Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
- "Recommendations for Key Management", NIST SP 800-57,
- March 2007.
-
- [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
- Standards (PKCS) #1: RSA Cryptography Specifications
- Version 2.1", RFC 3447, February 2003.
-
- [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-Authors' Addresses
-
-
-Vasily Dolmatov, Ed.
-Cryptocom Ltd.
-Bolotnikovskaya, 23
-Moscow, 117303, Russian Federation
-
-EMail: dol@cryptocom.ru
-
-Artem Chuprina
-Cryptocom Ltd.
-Bolotnikovskaya, 23
-Moscow, 117303, Russian Federation
-
-EMail: ran@cryptocom.ru
-
-Igor Ustinov
-Cryptocom Ltd.
-Bolotnikovskaya, 23
-Moscow, 117303, Russian Federation
-
-EMail: igus@cryptocom.ru
-
- Expires December 31, 2009 [Page ]
-
-
+++ /dev/null
-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
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
- (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
- RFC 4787, January 2007.
-
- [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
- Nameservers in Reflector Attacks", BCP 140, RFC 5358,
- October 2008.
-
- [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
- Resilient against Forged Answers", RFC 5452, January 2009.
-
-10.2. Informative References
-
- [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
- Routers", February 2008,
- <http://www.iis.se/docs/Routertester_en.pdf>.
-
- [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
- Broadband Routers and Firewalls", September 2008,
- <http://www.icann.org/committees/security/sac035.pdf>.
-
-
-Author's Address
-
- Ray Bellis
- Nominet UK
- Edmund Halley Road
- Oxford OX4 4DQ
- United Kingdom
-
- Phone: +44 1865 332211
- Email: ray.bellis@nominet.org.uk
- URI: http://www.nominet.org.uk/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis Expires October 25, 2009 [Page 13]
-\f
+++ /dev/null
-
-
-
-DNSOP W. Hardaker
-Internet-Draft Sparta, Inc.
-Intended status: Informational February 12, 2009
-Expires: August 16, 2009
-
-
- Requirements for Management of Name Servers for the DNS
- draft-ietf-dnsop-name-server-management-reqs-02.txt
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 16, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document.
-
-Abstract
-
- Management of name servers for the Domain Name Service (DNS) has
- traditionally been done using vendor-specific monitoring,
-
-
-
-Hardaker Expires August 16, 2009 [Page 1]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- configuration and control methods. Although some service monitoring
- platforms can test the functionality of the DNS itself there is not a
- interoperable way to manage (monitor, control and configure) the
- internal aspects of a name server itself.
-
- This document discusses the requirements of a management system for
- DNS name servers. A management solution that is designed to manage
- the DNS can use this document as a shopping list of needed features.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
- 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5
- 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5
- 2. Management Architecture Requirements . . . . . . . . . . . . . 5
- 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
- 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5
- 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
- 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
- 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
- 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
- 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
- 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
- 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
- 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
- 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
- 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
- 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
- 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
- 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
- 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
- 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
- 3.2.5. DNS Protocol Authorization Management . . . . . . . . 9
- 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
- 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10
- 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
- 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
- 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
- 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
- 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11
- 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
- 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
- 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
- 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
- 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
- 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
-
-
-
-Hardaker Expires August 16, 2009 [Page 2]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
- 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
- Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15
- A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
- A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
- A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 3]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-1. Introduction
-
- Management of name servers for the Domain Name Service (DNS)
- [RFC1034] [RFC1035] has traditionally been done using vendor-specific
- monitoring, configuration and control methods. Although some service
- monitoring platforms can test the functionality of the DNS itself
- there is not a interoperable way to manage (monitor, control and
- configure) the internal aspects of a name server itself.
-
- Previous standardization work within the IETF resulted in the
- creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
- to achieve significant implementation and deployment. The perceived
- reasons behind the failure for the two MIB modules are further
- documented in [RFC3197].
-
- This document discusses the requirements of a management system for
- DNS name servers. A management solution that is designed to manage
- the DNS can use this document as a shopping list of needed features.
-
- Specifically out of scope for this document are requirements
- associated with management of stub resolvers. It is not the intent
- of this document to document stub resolver requirements, although
- some of the requirements listed are applicable to stub resolvers as
- well.
-
- Also out of scope for this document is management of the host or
- other components of the host upon which the name server software is
- running. This document only discusses requirements for managing the
- name server component of a system.
-
- The task of creating a management system for managing DNS servers is
- not expected to be a small one. It is likely that components of the
- solution will need to be designed in parts over time and these
- requirements take this into consideration. In particular,
- Section 5.1 discusses the need for future extensibility of the base
- management solution. This document is intended to be a road-map
- towards a desired outcome and is not intended to define an "all-or-
- nothing" system. Successful interoperable management of name servers
- even in part is expected to be beneficial to network operators
- compared to the entirely custom solutions that are used at the time
- of this writing.
-
-1.1. Requirements notation
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 4]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-1.1.1. Terminology
-
- This document is consistent with the terminology defined in Section 2
- of [RFC4033]. Additional terminology needed for this document is
- described below:
-
- Name Server: When we are discussing servers that don't fall into a
- more specific type of server category defined in other documents,
- this document will refer to them generically as "name servers".
- In particular "name servers" can be considered to be any valid
- combination of authoritative, recursive, validating, or security-
- aware. The more specific name server labels will be used when
- this document refers only to a specific type of server. However,
- the term "name server", in this document, will not include stub
- resolvers.
-
-1.1.2. Document Layout and Requirements
-
- The document is written so that each numbered section will contain
- only a single requirement if it contains one at all. Each
- requirement will contain needed wording from the terminology
- described in Section 1.1. Subsections, however, might exist with
- additional related requirements. The document is laid out in this
- way so that a specific requirement can be uniquely referred to using
- the section number itself and the document version from which it
- came.
-
-
-2. Management Architecture Requirements
-
- This section discusses requirements that reflect the needs of the
- expected deployment environments.
-
-2.1. Expected Deployment Scenarios
-
- DNS zones vary greatly in the type of content published within them.
- Name Servers, too, are deployed with a wide variety of configurations
- to support the diversity of the deployed content. It is important
- that a management solution trying to meet the criteria specified in
- this document consider supporting the largest number of potential
- deployment cases as possible. Further deployment scenarios that are
- not used as direct examples of specific requirements are listed in
- Appendix A.
-
-2.1.1. Zone Size Constraints
-
- The management solution MUST support both name servers that are
- serving a small number of potentially very large zones (e.g. Top
-
-
-
-Hardaker Expires August 16, 2009 [Page 5]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- Level Domains (TLDs)) as well as name servers that are serving a very
- large number of small zones. These scenarios are both commonly seen
- deployments.
-
-2.1.2. Name Server Discovery
-
- Large enterprise network deployments may contain multiple name
- servers operating within the boundaries of the enterprise network.
- These name servers may each be serving multiple zones both in and out
- of the parent enterprise's zone. Finding and managing large
- quantities of name servers would be a useful feature of the resulting
- management solution. The management solution MAY support the ability
- to discover previously unknown instances of name servers operating
- within a deployed network.
-
-2.1.3. Configuration Data Volatility
-
- Configuration data is defined as data that relates only to the
- configuration of a server and the zones it serves. It specifically
- does not include data from the zone contents that is served through
- DNS itself. The solution MUST support servers that remain fairly
- statically configured over time as well as servers that have numerous
- zones being added and removed within an hour. Both of these
- scenarios are also commonly seen deployments.
-
-2.1.4. Protocol Selection
-
- There are many requirements in this document for many different types
- of management operations (see Section 3 for further details). It is
- possible that no one protocol will ideally fill all the needs of the
- requirements listed in this document and thus multiple protocols
- might be needed to produce a completely functional management system.
- Multiple protocols might be used to create the complete management
- solution, but the number of protocols used SHOULD be reduced to a
- reasonable minimum number.
-
-2.1.5. Common Data Model
-
- Defining a standardized protocol (or set of protocols) to use for
- managing name servers would be a step forward in achieving an
- interoperable management solution. However, just defining a protocol
- to use by itself would not achieve the complete end goal of a
- complete interoperable management solution. Devices also need to
- represent their internal management interface using a common
- management data model. The solution MUST create a common data model
- that management stations can make use of when sending or collecting
- data from a managed device so it can successfully manage equipment
- from vendors as if they were generic DNS servers. This common data
-
-
-
-Hardaker Expires August 16, 2009 [Page 6]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- model is needed for of the operations discussion in Section 3. Note
- that this does not preclude the fact that name server vendors might
- provide additional management infrastructure beyond a base management
- specification, as discussed further in Section 5.1.
-
-2.1.6. Operational Impact
-
- It is impossible to add new features to an existing server (such as
- the inclusion of a management infrastructure) and not impact the
- existing service and/or server in some fashion. At a minimum, for
- example, more memory, disk and/or CPU resources will be required to
- implement a new management system. However, the impact to the
- existing DNS service MUST be minimized since the DNS service itself
- is still the primary service to be offered by the modified name
- server.
-
-2.2. Name Server Types
-
- There are multiple ways in which name servers can be deployed. Name
- servers can take on any of the following roles:
-
- o Master Servers
-
- o Slave Servers
-
- o Recursive Servers
-
- The management solution SHOULD support all of these types of name
- servers as they are all equally important. Note that "Recursive
- Servers" can be further broken down by the security sub-roles they
- might implement, as defined in section 2 of [RFC4033]. These sub-
- roles are also important to support within any management solution.
-
- As stated earlier, the management of stub resolvers is considered out
- of scope for this documents.
-
-
-3. Management Operation Types
-
- Management operations can traditionally be broken into four
- categories:
-
- o Control
-
- o Configuration
-
- o Health and Monitoring
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 7]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- o Alarms and Events
-
- This section discusses requirements for each of these four management
- types in detail.
-
-3.1. Control Requirements
-
- The management solution MUST be capable of performing basic service
- control operations.
-
-3.1.1. Needed Control Operations
-
- These operations SHOULD include, at a minimum, the following
- operations:
-
- o Starting the name server
-
- o Reloading the service configuration
-
- o Reloading zone data
-
- o Restarting the name server
-
- o Stopping the name server
-
- Note that no restriction is placed on how the management system
- implements these operations. In particular, at least "starting the
- name server" will require a minimal management system component to
- exist independently of the name server itself.
-
-3.1.2. Asynchronous Status Notifications
-
- Some control operations might take a long time to complete. As an
- example, some name servers take a long time to perform reloads of
- large zones. Because of these timing issues, the management solution
- SHOULD take this into consideration and offer a mechanism to ease the
- burden associated with awaiting the status of a long-running command.
- This could, for example, result in the use of asynchronous
- notifications for returning the status of a long-running task or it
- might require the management station to poll for the status of a
- given task using monitoring commands. These and other potential
- solutions need to be evaluated carefully to select one that balances
- the result delivery needs with the perceived implementation costs.
-
- Also, see the related discussion in Section 3.4 on notification
- messages for supporting delivery of alarm and event messages.
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 8]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-3.2. Configuration Requirements
-
- Many features of name servers need to be configured before the server
- can be considered functional. The management solution MUST be able
- to provide name servers with configuration data. The most important
- data to be configured, for example, is the served zone data itself.
-
-3.2.1. Served Zone Modification
-
- The ability to add, modify and delete zones being served by name
- servers is needed. Although there are already solutions for zone
- content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
- AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
- might be used as part of the final management solution, the
- management system SHOULD still be able to natively create a new zone
- (with enough minimal data to allow the other mechanisms to function
- as well) as well as delete a zone. This might be, for example, a
- management operation that at least allows for the creation of the
- initial SOA record for a new zone as that's the minimum amount of
- zone data needed for the other operations to function.
-
-3.2.2. Trust Anchor Management
-
- The solution SHOULD support the ability to add, modify and delete
- trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
- [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust
- anchors might be configured using the data from the DNSKEY Resource
- Records (RRs) themselves or by using Delegation Signer (DS)
- fingerprints.
-
-3.2.3. Security Expectations
-
- DNSSEC Validating resolvers need to make policy decisions about the
- requests being processed. For example, they need to be configured
- with a list of zones expected to be secured by DNSSEC. The
- management solution SHOULD be able to add, modify and delete
- attributes of DNSSEC security policies.
-
-3.2.4. TSIG Key Management
-
- TSIG [RFC2845] allows transaction level authentication of DNS
- traffic. The management solution SHOULD be able to add, modify and
- delete TSIG keys known to the name server.
-
-3.2.5. DNS Protocol Authorization Management
-
- The management solution SHOULD have the ability to add, modify and
- delete authorization settings for the DNS protocols itself. Do not
-
-
-
-Hardaker Expires August 16, 2009 [Page 9]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- confuse this with the ability to manage the authorization associated
- with the management protocol itself, which is discussed later in
- Section 4.4. There are a number of authorization settings that are
- used by a name server. Example authorization settings that the
- solution might need to cover are:
-
- o Access to operations on zone data (e.g. DDNS)
-
- o Access to certain zone data from certain sources (e.g. from
- particular network subnets)
-
- o Access to specific DNS protocol services (e.g. recursive service)
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed authorization
- protections.
-
-3.3. Monitoring Requirements
-
- Monitoring is the process of collecting aspects of the internal state
- of a name server at a given moment in time. The solution MUST be
- able to monitor the health of a name server to determine its
- operational status, load and other internal attributes. Example
- management tasks that the solution might need to cover are:
-
- o Number of requests sent, responses sent, average response latency
- and other performance counters
-
- o Server status (e.g. "serving data", "starting up", "shutting
- down", ...)
-
- o Access control violations
-
- o List of zones being served
-
- o Detailed statistics about clients interacting with the name server
- (e.g. top 10 clients requesting data).
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed monitoring operations.
- In particular, some monitoring statistics are expected to be
- computationally or resource expensive and are considered to be "nice
- to haves" as opposed to "necessary to have".
-
-3.4. Alarm and Event Requirements
-
- Events occurring at the name server that trigger alarm notifications
- can quickly inform a management station about critical issues. A
-
-
-
-Hardaker Expires August 16, 2009 [Page 10]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- management solution SHOULD include support for delivery of alarm
- conditions.
-
- Example alarm conditions might include:
-
- o The server's status is changing. (e.g it is starting up, reloading
- configuration, restarting or shutting down)
-
- o A needed resource (e.g. memory or disk space) is exhausted or
- nearing exhaustion
-
- o An authorization violation was detected
-
- o The server has not received any data traffic (e.g. DNS requests
- or NOTIFYs) recently (AKA the "lonely warning"). This condition
- might indicate a problem with its deployment.
-
-
-4. Security Requirements
-
- The management solution will need to be appropriately secured against
- attacks on the management infrastructure.
-
-4.1. Authentication
-
- The solution MUST support mutual authentication. The management
- client needs to be assured that the management operations are being
- transferred to and from the correct name server. The managed name
- server needs to authenticate the system that is accessing the
- management infrastructure within itself.
-
-4.2. Integrity Protection
-
- Management operations MUST be protected from modification while in
- transit from the management client to the server.
-
-4.3. Confidentiality
-
- The management solution MUST support message confidentiality. The
- potential transfer of sensitive configuration is expected (such as
- TSIG keys or security policies). The solution does not, however,
- necessarily need to provide confidentiality to data that would
- normally be carried without confidentiality by the DNS system itself.
-
-4.4. Authorization
-
- The solution SHOULD be capable of providing a fine-grained
- authorization model for any management protocols it introduces to the
-
-
-
-Hardaker Expires August 16, 2009 [Page 11]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- completed system. This authorization differs from the authorization
- previously discussed in Section 3.2.5 in that this requirement is
- concerned solely with authorization of the management system itself.
-
- There are a number of authorization settings that might be used by a
- managed system to determine whether the managing entity has
- authorization to perform the given management task. Example
- authorization settings that the solution might need to cover are:
-
- o Access to the configuration that specifies which zones are to be
- served
-
- o Access to the management system infrastructure
-
- o Access to other control operations
-
- o Access to other configuration operations
-
- o Access to monitoring operations
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed authorization
- protections.
-
-4.5. Solution Impacts on Security
-
- The solution MUST minimize the security risks introduced to the
- complete name server system. It is impossible to add new
- infrastructure to a server and not impact the security in some
- fashion as the introduction of a management protocol alone will
- provide a new avenue for potential attack. Although the added
- management benefits will be worth the increased risks, the solution
- still needs to minimize this impact as much as possible.
-
-
-5. Other Requirements
-
-5.1. Extensibility
-
- The management solution is expected to change and expand over time as
- lessons are learned and new DNS features are deployed. Thus, the
- solution MUST be flexible and be able to accommodate new future
- management operations. The solution might, for example, make use of
- protocol versioning or capability description exchanges to ensure
- that management stations and name servers that weren't written to the
- same specification version can still interoperate to the best of
- their combined ability.
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 12]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-5.1.1. Vendor Extensions
-
- It MUST be possible for vendors to extend the standardized management
- model with vendor-specific extensions to support additional features
- offered by their products.
-
-5.1.2. Extension Identification
-
- It MUST be possible for a management station to understand which
- parts of returned data are specific to a given vendor or other
- standardized extension. The data returned needs to be appropriately
- marked through the use of name spaces or similar mechanisms to ensure
- that the base management model data can be logically separated from
- extension data without needing to understand the extension data
- itself.
-
-5.1.3. Name-Space Collision Protection
-
- It MUST be possible to protect against multiple extensions
- conflicting with each other. The use of name-space protection
- mechanisms for communicated management variables is common practice
- to protect against problems. Name-space identification techniques
- also frequently solve the "Extension Identification" requirement
- discussed in Section 5.1.2 as well.
-
-
-6. Security Considerations
-
- Any management protocol that meets the criteria discussed in this
- document needs to support the criteria discussed in Section 4 in
- order to protect the management infrastructure itself. The DNS is a
- core Internet service and management traffic that protects it could
- be the target of attacks designed to subvert that service. Because
- the management infrastructure will be adding additional interfaces to
- that service, it is critical that the management infrastructure
- support adequate protections against network attacks.
-
-
-7. IANA Considerations
-
- No action is required from IANA for this document.
-
-
-8. Document History
-
- A requirement gathering discussion was held at the December 2007 IETF
- meeting in Vancouver, BC, Canada and a follow up meeting was held at
- the March 2008 IETF meeting in Philadelphia. This document is a
-
-
-
-Hardaker Expires August 16, 2009 [Page 13]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- compilation of the results of those discussions as well as
- discussions on the DCOMA mailing list.
-
-
-9. Acknowledgments
-
- This draft is the result of discussions within the DCOMA design team
- chaired by Jaap Akkerhuis. This team consisted of a large number of
- people all of whom provided valuable insight and input into the
- discussions surrounding name server management. The text of this
- document was written from notes taken during meetings as well as from
- contributions sent to the DCOMA mailing list. This work documents
- the consensus of the DCOMA design team.
-
- In particular, the following team members contributed significantly
- to the text in the document:
-
- Stephane Bortzmeyer
-
- Stephen Morris
-
- Phil Regnauld
-
- Further editing contributions and wording suggestions were made by:
- Alfred Hoenes.
-
-
-10. References
-
-10.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
- August 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-
-
-
-Hardaker Expires August 16, 2009 [Page 14]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
- Trust Anchors", RFC 5011, September 2007.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-10.2. Informative References
-
- [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
- RFC 1611, May 1994.
-
- [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
- RFC 1612, May 1994.
-
- [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
- and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
- July 1997.
-
- [RFC3197] Austein, R., "Applicability Statement for DNS MIB
- Extensions", RFC 3197, November 2001.
-
-
-Appendix A. Deployment Scenarios
-
- This appendix documents some additional deployment scenarios that
- have been traditionally difficult to manage. They are provided as
-
-
-
-Hardaker Expires August 16, 2009 [Page 15]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- guidance to protocol developers as data points of real-world name
- server management problems.
-
-A.1. Non-Standard Zones
-
- If an organization uses non-standard zones (for example a purely-
- local TLD), synchronizing all the name servers for these zones is
- usually a time-consuming task. It is made worse when two
- organizations with conflicting zones merge. This situation is not a
- recommended deployment scenario (and is even heavily discouraged) but
- it is, unfortunately, seen in the wild.
-
- It is typically implemented using "forwarding" zones. But there is
- no way to ensure automatically that all the resolvers have the same
- set of zones to forward at any given time. New zones might be added
- to a local forwarding recursive server, for example, without
- modifying the rest of the deployed forwarding servers. It is hoped
- that a management solution which could handle the configuration of
- zone forwarding would finally allow management of servers deployed in
- this fashion.
-
-A.2. Redundancy Sharing
-
- For reliability reasons it is recommended that zone operators follow
- the guidelines documented in [RFC2182] which recommends that multiple
- name servers be configured for each zone and that the name servers
- are separated both physically and via connectivity routes. A common
- solution is to establish DNS-serving partnerships: "I'll host your
- zones and you'll host mine". Both entities benefit from increased
- DNS reliability via the wider service distribution. This frequently
- occurs between cooperating but otherwise unrelated entities (such as
- between two distinct companies) as well as between affiliated
- organizations (such as between branch offices within a single
- company).
-
- The configuration of these relationships are currently required to be
- manually configured and maintained. Changes to the list of zones
- that are cross-hosted are manually negotiated between the cooperating
- network administrators and configured by hand. A management protocol
- with the ability to provide selective authorization, as discussed in
- Section 4.4, would solve many of the management difficulties between
- cooperating organizations.
-
-A.3. DNSSEC Management
-
- There are many different DNSSEC deployment strategies that may be
- used for mission-critical zones. The following list describes some
- example deployment scenarios that might warrant different management
-
-
-
-Hardaker Expires August 16, 2009 [Page 16]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- strategies.
-
- All contents and DNSSEC keying information controlled and operated
- by a single organization
-
- Zone contents controlled and operated by one organization, all
- DNSSEC keying information controlled and operated by a second
- organization.
-
- Zone contents controlled and operated by one organization, zone
- signing keys (ZSKs) controlled and operated by a second
- organization, and key signing keys (KSKs) controlled and operated
- by a third organization.
-
- Although this list is not exhaustive in the potential ways that zone
- data can be divided up, it should be sufficient to illustrate the
- potential ways in which zone data can be controlled by multiple
- entities.
-
- The end result of all of these strategies, however, will be the same:
- a live zone containing DNSSEC related resource records. Many of the
- above strategies are merely different ways of preparing a zone for
- serving. A management solution that includes support for managing
- DNSSEC zone data may wish to take into account these potential
- management scenarios.
-
-
-Author's Address
-
- Wes Hardaker
- Sparta, Inc.
- P.O. Box 382
- Davis, CA 95617
- US
-
- Phone: +1 530 792 1913
- Email: ietf@hardakers.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 17]
-\f
projects / thirdparty / bind9.git / commitdiff
