+++ /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
-
-
-
-DNSEXT D. Blacka
-Internet-Draft VeriSign, Inc.
-Intended status: Standards Track April 7, 2006
-Expires: October 9, 2006
-
-
- DNSSEC Experiments
- draft-ietf-dnsext-dnssec-experiments-03
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on October 9, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 1]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Abstract
-
- This document describes a methodology for deploying alternate, non-
- backwards-compatible, DNSSEC methodologies in an experimental fashion
- without disrupting the deployment of standard DNSSEC.
-
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8
- 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9
- 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
- 10.2. Informative References . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 2]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system (RFC 1035
- [5]) and the DNS security extensions ([2], [3], and [4] is assumed.
-
- The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 3]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-2. Overview
-
- Historically, experimentation with DNSSEC alternatives has been a
- problematic endeavor. There has typically been a desire to both
- introduce non-backwards-compatible changes to DNSSEC and to try these
- changes on real zones in the public DNS. This creates a problem when
- the change to DNSSEC would make all or part of the zone using those
- changes appear bogus (bad) or otherwise broken to existing security-
- aware resolvers.
-
- This document describes a standard methodology for setting up DNSSEC
- experiments. This methodology addresses the issue of co-existence
- with standard DNSSEC and DNS by using unknown algorithm identifiers
- to hide the experimental DNSSEC protocol modifications from standard
- security-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 4]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-3. Experiments
-
- When discussing DNSSEC experiments, it is necessary to classify these
- experiments into two broad categories:
-
- Backwards-Compatible: describes experimental changes that, while not
- strictly adhering to the DNSSEC standard, are nonetheless
- interoperable with clients and servers that do implement the
- DNSSEC standard.
-
- Non-Backwards-Compatible: describes experiments that would cause a
- standard security-aware resolver to (incorrectly) determine that
- all or part of a zone is bogus, or to otherwise not interoperate
- with standard DNSSEC clients and servers.
-
- Not included in these terms are experiments with the core DNS
- protocol itself.
-
- The methodology described in this document is not necessary for
- backwards-compatible experiments, although it certainly may be used
- if desired.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 5]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-4. Method
-
- The core of the methodology is the use of strictly unknown algorithm
- identifiers when signing the experimental zone, and more importantly,
- having only unknown algorithm identifiers in the DS records for the
- delegation to the zone at the parent.
-
- This technique works because of the way DNSSEC-compliant validators
- are expected to work in the presence of a DS set with only unknown
- algorithm identifiers. From [4], Section 5.2:
-
- If the validator does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
- And further:
-
- If the resolver does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver will not be able to
- verify the authentication path to the child zone. In this case,
- the resolver SHOULD treat the child zone as if it were unsigned.
-
- While this behavior isn't strictly mandatory (as marked by MUST), it
- is likely that a validator would implement this behavior, or, more to
- the point, it would handle this situation in a safe way (see below
- (Section 6).)
-
- Because we are talking about experiments, it is RECOMMENDED that
- private algorithm numbers be used (see [3], appendix A.1.1. Note
- that secure handling of private algorithms requires special handing
- by the validator logic. See [6] for further details.) Normally,
- instead of actually inventing new signing algorithms, the recommended
- path is to create alternate algorithm identifiers that are aliases
- for the existing, known algorithms. While, strictly speaking, it is
- only necessary to create an alternate identifier for the mandatory
- algorithms, it is suggested that all optional defined algorithms be
- aliased as well.
-
- It is RECOMMENDED that for a particular DNSSEC experiment, a
- particular domain name base is chosen for all new algorithms, then
- the algorithm number (or name) is prepended to it. For example, for
- experiment A, the base name of "dnssec-experiment-a.example.com" is
- chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
- defined to be "3.dnssec-experiment-a.example.com" and
- "5.dnssec-experiment-a.example.com". However, any unique identifier
-
-
-
-Blacka Expires October 9, 2006 [Page 6]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
- will suffice.
-
- Using this method, resolvers (or, more specifically, DNSSEC
- validators) essentially indicate their ability to understand the
- DNSSEC experiment's semantics by understanding what the new algorithm
- identifiers signify.
-
- This method creates two classes of security-aware servers and
- resolvers: servers and resolvers that are aware of the experiment
- (and thus recognize the experiment's algorithm identifiers and
- experimental semantics), and servers and resolvers that are unaware
- of the experiment.
-
- This method also precludes any zone from being both in an experiment
- and in a classic DNSSEC island of security. That is, a zone is
- either in an experiment and only experimentally validatable, or it is
- not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 7]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-5. Defining an Experiment
-
- The DNSSEC experiment MUST define the particular set of (previously
- unknown) algorithm identifiers that identify the experiment, and
- define what each unknown algorithm identifier means. Typically,
- unless the experiment is actually experimenting with a new DNSSEC
- algorithm, this will be a mapping of private algorithm identifiers to
- existing, known algorithms.
-
- Normally the experiment will choose a DNS name as the algorithm
- identifier base. This DNS name SHOULD be under the control of the
- authors of the experiment. Then the experiment will define a mapping
- between known mandatory and optional algorithms into this private
- algorithm identifier space. Alternately, the experiment MAY use the
- OID private algorithm space instead (using algorithm number 254), or
- MAY choose non-private algorithm numbers, although this would require
- an IANA allocation.
-
- For example, an experiment might specify in its description the DNS
- name "dnssec-experiment-a.example.com" as the base name, and declare
- that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
- algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
- alias of DNSSEC algorithm 5 (RSASHA1).
-
- Resolvers MUST only recognize the experiment's semantics when present
- in a zone signed by one or more of these algorithm identifiers. This
- is necessary to isolate the semantics of one experiment from any
- others that the resolver might understand.
-
- In general, resolvers involved in the experiment are expected to
- understand both standard DNSSEC and the defined experimental DNSSEC
- protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 8]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-6. Considerations
-
- There are a number of considerations with using this methodology.
-
- 1. Under some circumstances, it may be that the experiment will not
- be sufficiently masked by this technique and may cause resolution
- problem for resolvers not aware of the experiment. For instance,
- the resolver may look at a non-validatable response and conclude
- that the response is bogus, either due to local policy or
- implementation details. This is not expected to be a common
- case, however.
-
- 2. It will not be possible for security-aware resolvers unaware of
- the experiment to build a chain of trust through an experimental
- zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 9]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-7. Use in Non-Experiments
-
- This general methodology MAY be used for non-backwards compatible
- DNSSEC protocol changes that start out as or become standards. In
- this case:
-
- o The protocol change SHOULD use public IANA allocated algorithm
- identifiers instead of private algorithm identifiers. This will
- help identify the protocol change as a standard, rather than an
- experiment.
-
- o Resolvers MAY recognize the protocol change in zones not signed
- (or not solely signed) using the new algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 10]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-8. Security Considerations
-
- Zones using this methodology will be considered insecure by all
- resolvers except those aware of the experiment. It is not generally
- possible to create a secure delegation from an experimental zone that
- will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 11]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-9. IANA Considerations
-
- This document has no IANA actions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 12]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-10. References
-
-10.1. Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
-10.2. Informative References
-
- [5] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [6] Austein, R. and S. Weiler, "Clarifications and Implementation
- Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
- (work in progress), January 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 13]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Author's Address
-
- David Blacka
- VeriSign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- Email: davidb@verisign.com
- URI: http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 14]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 15]
-\f
+++ /dev/null
-
-This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted
-from the Internet-Drafts directory. An Internet-Draft expires 185 days from
-the date that it is posted unless it is replaced by an updated version, or the
-Secretariat has been notified that the document is under official review by the
-IESG or has been passed to the RFC Editor for review and/or publication as an
-RFC. This Internet-Draft was not published as an RFC.
-
-Internet-Drafts are not archival documents, and copies of Internet-Drafts that have
-been deleted from the directory are not available. The Secretariat does not have
-any information regarding the future plans of the author(s) or working group, if
-applicable, with respect to this deleted Internet-Draft. For more information, or
-to request a copy of the document, please contact the author(s) directly.
-
-Draft Author(s):
-Remco van Mook <remco@virtu.nl>,
-Bert Hubert <bert.hubert@netherlabs.nl>
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Bernard Aboba
-INTERNET-DRAFT Dave Thaler
-Category: Standards Track Levon Esibov
-<draft-ietf-dnsext-mdns-46.txt> Microsoft Corporation
-16 April 2006
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on October 15, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2006.
-
-Abstract
-
- The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
- name resolution in scenarios in which conventional DNS name
- resolution is not possible. LLMNR supports all current and future
- DNS formats, types and classes, while operating on a separate port
- from DNS, and with a distinct resolver cache. Since LLMNR only
- operates on the local link, it cannot be considered a substitute for
- DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name Resolution Using LLMNR ........................... 4
- 2.1 LLMNR Packet Format ............................. 5
- 2.2 Sender Behavior ................................. 8
- 2.3 Responder Behavior .............................. 8
- 2.4 Unicast Queries and Responses ................... 11
- 2.5 Off-link Detection .............................. 11
- 2.6 Responder Responsibilities ...................... 12
- 2.7 Retransmission and Jitter ....................... 13
- 2.8 DNS TTL ......................................... 14
- 2.9 Use of the Authority and Additional Sections .... 14
-3. Usage model ........................................... 15
- 3.1 LLMNR Configuration ............................. 16
-4. Conflict Resolution ................................... 18
- 4.1 Uniqueness Verification ......................... 18
- 4.2 Conflict Detection and Defense .................. 19
- 4.3 Considerations for Multiple Interfaces .......... 20
- 4.4 API issues ...................................... 22
-5. Security Considerations ............................... 22
- 5.1 Denial of Service ............................... 22
- 5.2 Spoofing ...............,........................ 23
- 5.3 Authentication .................................. 24
- 5.4 Cache and Port Separation ....................... 24
-6. IANA considerations ................................... 25
-7. Constants ............................................. 25
-8. References ............................................ 26
- 8.1 Normative References ............................ 26
- 8.2 Informative References .......................... 26
-Acknowledgments .............................................. 28
-Authors' Addresses ........................................... 28
-Intellectual Property Statement .............................. 29
-Disclaimer of Validity ....................................... 29
-Copyright Statement .......................................... 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which is based on the DNS packet format and supports all current and
- future DNS formats, types and classes. LLMNR operates on a separate
- port from the Domain Name System (DNS), with a distinct resolver
- cache.
-
- Since LLMNR only operates on the local link, it cannot be considered
- a substitute for DNS. Link-scope multicast addresses are used to
- prevent propagation of LLMNR traffic across routers, potentially
- flooding the network. LLMNR queries can also be sent to a unicast
- address, as described in Section 2.4.
-
- Propagation of LLMNR packets on the local link is considered
- sufficient to enable name resolution in small networks. In such
- networks, if a network has a gateway, then typically the network is
- able to provide DNS server configuration. Configuration issues are
- discussed in Section 3.1.
-
- In the future, it may be desirable to consider use of multicast name
- resolution with multicast scopes beyond the link-scope. This could
- occur if LLMNR deployment is successful, the need arises for
- multicast name resolution beyond the link-scope, or multicast routing
- becomes ubiquitous. For example, expanded support for multicast name
- resolution might be required for mobile ad-hoc networks.
-
- Once we have experience in LLMNR deployment in terms of
- administrative issues, usability and impact on the network, it will
- be possible to reevaluate which multicast scopes are appropriate for
- use with multicast name resolution. IPv4 administratively scoped
- multicast usage is specified in "Administratively Scoped IP
- Multicast" [RFC2365].
-
- Service discovery in general, as well as discovery of DNS servers
- using LLMNR in particular, is outside of the scope of this document,
- as is name resolution over non-multicast capable media.
-
-1.1. Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. 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].
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1.2. Terminology
-
- This document assumes familiarity with DNS terminology defined in
- [RFC1035]. Other terminology used in this document includes:
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An LLMNR responder considers one of its addresses reachable over a
- link if it will respond to an ARP or Neighbor Discovery query for
- that address received on that link.
-
-Responder
- A host that listens to LLMNR queries, and responds to those for
- which it is authoritative.
-
-Sender
- A host that sends an LLMNR query.
-
-UNIQUE
- There are some scenarios when multiple responders may respond to
- the same query. There are other scenarios when only one responder
- may respond to a query. Names for which only a single responder is
- anticipated are referred to as UNIQUE. Name uniqueness is
- configured on the responder, and therefore uniqueness verification
- is the responder's responsibility.
-
-2. Name Resolution Using LLMNR
-
- LLMNR queries are sent to and received on port 5355. The IPv4 link-
- scope multicast address a given responder listens to, and to which a
- sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
- address a given responder listens to, and to which a sender sends all
- queries, is FF02:0:0:0:0:0:1:3.
-
- Typically a host is configured as both an LLMNR sender and a
- responder. A host MAY be configured as a sender, but not a
- responder. However, a host configured as a responder MUST act as a
- sender, if only to verify the uniqueness of names as described in
- Section 4. This document does not specify how names are chosen or
- configured. This may occur via any mechanism, including DHCPv4
- [RFC2131] or DHCPv6 [RFC3315].
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] An LLMNR sender sends an LLMNR query to the link-scope
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- multicast address(es), unless a unicast query is indicated,
- as specified in Section 2.4.
-
- [b] A responder responds to this query only if it is authoritative
- for the name in the query. A responder responds to a
- multicast query by sending a unicast UDP response to the sender.
- Unicast queries are responded to as indicated in Section 2.4.
-
- [c] Upon reception of the response, the sender processes it.
-
- The sections that follow provide further details on sender and
- responder behavior.
-
-2.1. LLMNR Packet Format
-
- LLMNR is based on the DNS packet format defined in [RFC1035] Section
- 4 for both queries and responses. LLMNR implementations SHOULD send
- UDP queries and responses only as large as are known to be
- permissible without causing fragmentation. When in doubt a maximum
- packet size of 512 octets SHOULD be used. LLMNR implementations MUST
- accept UDP queries and responses as large as the smaller of the link
- MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
- octets for the header, VLAN tag and CRC).
-
-2.1.1. LLMNR Header Format
-
- LLMNR queries and responses utilize the DNS header format defined in
- [RFC1035] with exceptions noted below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value. For advice on generation of pseudo-random values, please
- consult [RFC1750].
-
-QR Query/Response. A one bit field, which if set indicates that the
- message is an LLMNR response; if clear then the message is an LLMNR
- query.
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-C Conflict. When set within a request, the 'C'onflict bit indicates
- that a sender has received multiple LLMNR responses to this query.
- In an LLMNR response, if the name is considered UNIQUE, then the
- 'C' bit is clear, otherwise it is set. LLMNR senders do not
- retransmit queries with the 'C' bit set. Responders MUST NOT
- respond to LLMNR queries with the 'C' bit set, but may start the
- uniqueness verification process, as described in Section 4.2.
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set in an LLMNR response,
- then the sender SHOULD resend the LLMNR query over TCP using the
- unicast address of the responder as the destination address. If
- the sender receives a response to the TCP query, then it SHOULD
- discard the UDP response with the TC bit set. See [RFC2181] and
- Section 2.4 of this specification for further discussion of the TC
- bit.
-
-T Tentative. The 'T'entative bit is set in a response if the
- responder is authoritative for the name, but has not yet verified
- the uniqueness of the name. A responder MUST ignore the 'T' bit in
- a query, if set. A response with the 'T' bit set is silently
- discarded by the sender, except if it is a uniqueness query, in
- which case a conflict has been detected and a responder MUST
- resolve the conflict as described in Section 4.1.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the sender MUST set RCODE to zero;
- the responder ignores the RCODE and assumes it to be zero. The
- response to a multicast LLMNR query MUST have RCODE set to zero. A
- sender MUST silently discard an LLMNR response with a non-zero
- RCODE sent in response to a multicast query.
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferable to not
- sending a response, since it enables errors to be diagnosed. This
- may be required, for example, when an LLMNR query includes a TSIG
- RR in the additional section, and the responder encounters a
- problem that requires returning a non-zero RCODE. TSIG error
- conditions defined in [RFC2845] include a TSIG RR in an
- unacceptable position (RCODE=1) or a TSIG RR which does not
- validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)).
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9. LLMNR
- responders MUST silently discard LLMNR queries with NSCOUNT not
- equal to zero.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender Behavior
-
- A sender MAY send an LLMNR query for any legal resource record type
- (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
- As described in Section 2.4, a sender MAY also send a unicast query.
-
- The sender MUST anticipate receiving no replies to some LLMNR
- queries, in the event that no responders are available within the
- link-scope. If no response is received, a resolver treats it as a
- response that the name does not exist (RCODE=3 is returned). A
- sender can handle duplicate responses by discarding responses with a
- source IP address and ID field that duplicate a response already
- received.
-
- When multiple valid LLMNR responses are received with the 'C' bit
- set, they SHOULD be concatenated and treated in the same manner that
- multiple RRs received from the same DNS server would be. However,
- responses with the 'C' bit set SHOULD NOT be concatenated with
- responses with the 'C' bit clear; instead, only the responses with
- the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
- received along with error response(s), then the error responses are
- silently discarded.
-
- Since the responder may order the RRs in the response so as to
- indicate preference, the sender SHOULD preserve ordering in the
- response to the querying application.
-
-2.3. Responder Behavior
-
- An LLMNR response MUST be sent to the sender via unicast.
-
- Upon configuring an IP address, responders typically will synthesize
- corresponding A, AAAA and PTR RRs so as to be able to respond to
- LLMNR queries for these RRs. An SOA RR is synthesized only when a
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responder has another RR in addition to the SOA RR; the SOA RR MUST
- NOT be the only RR that a responder has. However, in general whether
- RRs are manually or automatically created is an implementation
- decision.
-
- For example, a host configured to have computer name "host1" and to
- be a member of the "example.com" domain, and with IPv4 address
- 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
- authoritative for the following records:
-
- host1. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- host1.example.com. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- 1.2.0.192.in-addr.arpa. IN PTR host1.
- IN PTR host1.example.com.
-
- 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
- ip6.arpa IN PTR host1. (line split for formatting reasons)
- IN PTR host1.example.com.
-
- An LLMNR responder might be further manually configured with the name
- of a local mail server with an MX RR included in the "host1." and
- "host1.example.com." records.
-
- In responding to queries:
-
-[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
- address(es) defined in Section 2, and on TCP port 5355 on the
- unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses MUST always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups, with the exception of queries with the 'C' bit
- set, which do not elicit a response.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[e] Responders MUST NOT respond using data from the LLMNR or DNS
- resolver cache.
-
-[f] If a DNS server is running on a host that supports LLMNR, the DNS
- server MUST respond to LLMNR queries only for the RRSets relating
- to the host on which the server is running, but MUST NOT respond
- for other records for which the server is authoritative. DNS
- servers also MUST NOT send LLMNR queries in order to resolve DNS
- queries.
-
-[g] If a responder is authoritative for a name, it MUST respond with
- RCODE=0 and an empty answer section, if the type of query does not
- match a RR that the responder has.
-
- As an example, a host configured to respond to LLMNR queries for the
- name "foo.example.com." is authoritative for the name
- "foo.example.com.". On receiving an LLMNR query for an A RR with the
- name "foo.example.com." the host authoritatively responds with A
- RR(s) that contain IP address(es) in the RDATA of the resource
- record. If the responder has a AAAA RR, but no A RR, and an A RR
- query is received, the responder would respond with RCODE=0 and an
- empty answer section.
-
- In conventional DNS terminology a DNS server authoritative for a zone
- is authoritative for all the domain names under the zone apex except
- for the branches delegated into separate zones. Contrary to
- conventional DNS terminology, an LLMNR responder is authoritative
- only for the zone apex.
-
- For example the host "foo.example.com." is not authoritative for the
- name "child.foo.example.com." unless the host is configured with
- multiple names, including "foo.example.com." and
- "child.foo.example.com.". As a result, "foo.example.com." cannot
- reply to an LLMNR query for "child.foo.example.com." with RCODE=3
- (authoritative name error). The purpose of limiting the name
- authority scope of a responder is to prevent complications that could
- be caused by coexistence of two or more hosts with the names
- representing child and parent (or grandparent) nodes in the DNS tree,
- for example, "foo.example.com." and "child.foo.example.com.".
-
- Without the restriction on authority an LLMNR query for an A resource
- record for the name "child.foo.example.com." would result in two
- authoritative responses: RCODE=3 (authoritative name error) received
- from "foo.example.com.", and a requested A record - from
- "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
- hosts could perform a dynamic update of the parent (or grandparent)
- zone with a delegation to a child zone; for example a host
- "child.foo.example.com." could send a dynamic update for the NS and
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- glue A record to "foo.example.com.". However, this approach
- significantly complicates implementation of LLMNR and would not be
- acceptable for lightweight hosts.
-
-2.4. Unicast Queries and Responses
-
- Unicast queries SHOULD be sent when:
-
- [a] A sender repeats a query after it received a response
- with the TC bit set to the previous LLMNR multicast query, or
-
- [b] The sender queries for a PTR RR of a fully formed IP address
- within the "in-addr.arpa" or "ip6.arpa" zones.
-
- Unicast LLMNR queries MUST be done using TCP and the responses MUST
- be sent using the same TCP connection as the query. Senders MUST
- support sending TCP queries, and responders MUST support listening
- for TCP queries. If the sender of a TCP query receives a response to
- that query not using TCP, the response MUST be silently discarded.
-
- Unicast UDP queries MUST be silently discarded.
-
- A unicast PTR RR query for an off-link address will not elicit a
- response, but instead an ICMP TTL or Hop Limit exceeded message will
- be received. An implementation receiving an ICMP message in response
- to a TCP connection setup attempt can return immediately, treating
- this as a response that no such name exists (RCODE=3 is returned).
- An implementation that cannot process ICMP messages MAY send
- multicast UDP queries for PTR RRs. Since TCP implementations will
- not retransmit prior to RTOmin, a considerable period will elapse
- before TCP retransmits multiple times, resulting in a long timeout
- for TCP PTR RR queries sent to an off-link destination.
-
-2.5. "Off link" Detection
-
- A sender MUST select a source address for LLMNR queries that is
- assigned on the interface on which the query is sent. The
- destination address of an LLMNR query MUST be a link-scope multicast
- address or a unicast address.
-
- A responder MUST select a source address for responses that is
- assigned on the interface on which the query was received. The
- destination address of an LLMNR response MUST be a unicast address.
-
- On receiving an LLMNR query, the responder MUST check whether it was
- sent to a LLMNR multicast addresses defined in Section 2. If it was
- sent to another multicast address, then the query MUST be silently
- discarded.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- Section 2.4 discusses use of TCP for LLMNR queries and responses. In
- composing an LLMNR query using TCP, the sender MUST set the Hop Limit
- field in the IPv6 header and the TTL field in the IPv4 header of the
- response to one (1). The responder SHOULD set the TTL or Hop Limit
- settings on the TCP listen socket to one (1) so that SYN-ACK packets
- will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
- prevents an incoming connection from off-link since the sender will
- not receive a SYN-ACK from the responder.
-
- For UDP queries and responses, the Hop Limit field in the IPv6 header
- and the TTL field in the IPV4 header MAY be set to any value.
- However, it is RECOMMENDED that the value 255 be used for
- compatibility with early implementations of [RFC3927].
-
- Implementation note:
-
- In the sockets API for IPv4 [POSIX], the IP_TTL and
- IP_MULTICAST_TTL socket options are used to set the TTL of
- outgoing unicast and multicast packets. The IP_RECVTTL socket
- option is available on some platforms to retrieve the IPv4 TTL of
- received packets with recvmsg(). [RFC2292] specifies similar
- options for setting and retrieving the IPv6 Hop Limit.
-
-2.6. Responder Responsibilities
-
- It is the responsibility of the responder to ensure that RRs returned
- in LLMNR responses MUST only include values that are valid on the
- local interface, such as IPv4 or IPv6 addresses valid on the local
- link or names defended using the mechanism described in Section 4.
- IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
- addresses are defined in [RFC2373]. In particular:
-
- [a] If a link-scope IPv6 address is returned in a AAAA RR,
- that address MUST be valid on the local link over which
- LLMNR is used.
-
- [b] If an IPv4 address is returned, it MUST be reachable
- through the link over which LLMNR is used.
-
- [c] If a name is returned (for example in a CNAME, MX
- or SRV RR), the name MUST be resolvable on the local
- link over which LLMNR is used.
-
- Where multiple addresses represent valid responses to a query, the
- order in which the addresses are returned is as follows:
-
- [d] If the source address of the query is a link-scope address,
- then the responder SHOULD include a link-scope address first
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- in the response, if available.
-
- [e] If the source address of the query is a routable address,
- then the responder MUST include a routable address first
- in the response, if available.
-
-2.7. Retransmission and Jitter
-
- An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
- when to retransmit an LLMNR query. An LLMNR sender SHOULD either
- estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
- high initial timeout. Suggested constants are described in Section
- 7.
-
- If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
- then a sender SHOULD repeat the transmission of the query in order to
- assure that it was received by a host capable of responding to it.
- An LLMNR query SHOULD NOT be sent more than three times.
-
- Where LLMNR queries are sent using TCP, retransmission is handled by
- the transport layer. Queries with the 'C' bit set MUST be sent using
- multicast UDP and MUST NOT be retransmitted.
-
- An LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
- has been received, or if it is necessary to collect all potential
- responses, such as if a uniqueness verification query is being made.
- Otherwise an LLMNR sender SHOULD consider a multicast query answered
- after the first response is received, if that response has the 'C'
- bit clear.
-
- However, if the first response has the 'C' bit set, then the sender
- SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect
- all possible responses. When multiple valid answers are received,
- they may first be concatenated, and then treated in the same manner
- that multiple RRs received from the same DNS server would. A unicast
- query sender considers the query answered after the first response is
- received.
-
- Since it is possible for a response with the 'C' bit clear to be
- followed by a response with the 'C' bit set, an LLMNR sender SHOULD
- be prepared to process additional responses for the purposes of
- conflict detection, even after it has considered a query answered.
-
- In order to avoid synchronization, the transmission of each LLMNR
- query and response SHOULD delayed by a time randomly selected from
- the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responders responding with names which they have previously
- determined to be UNIQUE (see Section 4 for details).
-
-2.8. DNS TTL
-
- The responder should insert a pre-configured TTL value in the records
- returned in an LLMNR response. A default value of 30 seconds is
- RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
- networks), the TTL value may need to be reduced.
-
- Due to the TTL minimalization necessary when caching an RRset, all
- TTLs in an RRset MUST be set to the same value.
-
-2.9. Use of the Authority and Additional Sections
-
- Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
- concept of delegation. In LLMNR, the NS resource record type may be
- stored and queried for like any other type, but it has no special
- delegation semantics as it does in the DNS. Responders MAY have NS
- records associated with the names for which they are authoritative,
- but they SHOULD NOT include these NS records in the authority
- sections of responses.
-
- Responders SHOULD insert an SOA record into the authority section of
- a negative response, to facilitate negative caching as specified in
- [RFC2308]. The TTL of this record is set from the minimum of the
- MINIMUM field of the SOA record and the TTL of the SOA itself, and
- indicates how long a resolver may cache the negative answer. The
- owner name of the SOA record (MNAME) MUST be set to the query name.
- The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
- by senders. Negative responses without SOA records SHOULD NOT be
- cached.
-
- In LLMNR, the additional section is primarily intended for use by
- EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
- senders MAY only include pseudo RR-types in the additional section of
- a query; unless the 'C' bit is set, responders MUST ignore the
- additional section of queries containing other RR types.
-
- In queries where the 'C' bit is set, the sender SHOULD include the
- conflicting RRs in the additional section. Since conflict
- notifications are advisory, responders SHOULD log information from
- the additional section, but otherwise MUST ignore the additional
- section.
-
- Senders MUST NOT cache RRs from the authority or additional section
- of a response as answers, though they may be used for other purposes
- such as negative caching.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-3. Usage Model
-
- LLMNR is a peer-to-peer name resolution protocol that is not intended
- as a replacement for DNS; rather, it enables name resolution in
- scenarios in which conventional DNS name resolution is not possible.
- This includes situations in which hosts are not configured with the
- address of a DNS server; where the DNS server is unavailable or
- unreachable; where there is no DNS server authoritative for the name
- of a host, or where the authoritative DNS server does not have the
- desired RRs.
-
- By default, an LLMNR sender SHOULD send LLMNR queries only for
- single-label names. In order to reduce unnecessary DNS queries, stub
- resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS
- queries for single-label names. An LLMNR sender SHOULD NOT be
- enabled to send a query for any name, except where security
- mechanisms (described in Section 5.3) can be utilized.
-
- Regardless of whether security mechanisms can be utilized, LLMNR
- queries SHOULD NOT be sent unless one of the following conditions are
- met:
-
- [1] No manual or automatic DNS configuration has been performed.
- If DNS server address(es) have been configured, a
- host SHOULD attempt to reach DNS servers over all protocols
- on which DNS server address(es) are configured, prior to sending
- LLMNR queries. For dual stack hosts configured with DNS server
- address(es) for one protocol but not another, this implies that
- DNS queries SHOULD be sent over the protocol configured with
- a DNS server, prior to sending LLMNR queries.
-
- [2] All attempts to resolve the name via DNS on all interfaces
- have failed after exhausting the searchlist. This can occur
- because DNS servers did not respond, or because they
- responded to DNS queries with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section. Where a
- single resolver call generates DNS queries for A and AAAA RRs,
- an implementation MAY choose not to send LLMNR queries if any
- of the DNS queries is successful. An LLMNR query SHOULD only
- be sent for the originally requested name; a searchlist
- is not used to form additional LLMNR queries.
-
- Since LLMNR is a secondary name resolution mechanism, its usage is in
- part determined by the behavior of DNS implementations. In general,
- robust DNS resolver implementations are more likely to avoid
- unnecessary LLMNR queries.
-
- As noted in [DNSPerf], even when DNS servers are configured, a
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- significant fraction of DNS queries do not receive a response, or
- result in negative responses due to missing inverse mappings or NS
- records that point to nonexistent or inappropriate hosts. This has
- the potential to result in a large number of unnecessary LLMNR
- queries.
-
- [RFC1536] describes common DNS implementation errors and fixes. If
- the proposed fixes are implemented, unnecessary LLMNR queries will be
- reduced substantially, and so implementation of [RFC1536] is
- recommended.
-
- For example, [RFC1536] Section 1 describes issues with retransmission
- and recommends implementation of a retransmission policy based on
- round trip estimates, with exponential back-off. [RFC1536] Section 4
- describes issues with failover, and recommends that resolvers try
- another server when they don't receive a response to a query. These
- policies are likely to avoid unnecessary LLMNR queries.
-
- [RFC1536] Section 3 describes zero answer bugs, which if addressed
- will also reduce unnecessary LLMNR queries.
-
- [RFC1536] Section 6 describes name error bugs and recommended
- searchlist processing that will reduce unnecessary RCODE=3
- (authoritative name) errors, thereby also reducing unnecessary LLMNR
- queries.
-
- If error responses are received from both DNS and LLMNR, then the
- lowest RCODE value should be returned. For example, if either DNS or
- LLMNR receives a response with RCODE=0, then this should returned to
- the caller.
-
-3.1. LLMNR Configuration
-
- LLMNR usage MAY be configured manually or automatically on a per
- interface basis. By default, LLMNR responders SHOULD be enabled on
- all interfaces, at all times. Enabling LLMNR for use in situations
- where a DNS server has been configured will result in a change in
- default behavior without a simultaneous update to configuration
- information. Where this is considered undesirable, LLMNR SHOULD NOT
- be enabled by default, so that hosts will neither listen on the link-
- scope multicast address, nor will they send queries to that address.
-
- Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
- possible for a dual stack host to be configured with the address of a
- DNS server over IPv4, while remaining unconfigured with a DNS server
- suitable for use over IPv6.
-
- In these situations, a dual stack host will send AAAA queries to the
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- configured DNS server over IPv4. However, an IPv6-only host
- unconfigured with a DNS server suitable for use over IPv6 will be
- unable to resolve names using DNS. Automatic IPv6 DNS configuration
- mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
- deployed, and not all DNS servers support IPv6. Therefore lack of
- IPv6 DNS configuration may be a common problem in the short term, and
- LLMNR may prove useful in enabling link-local name resolution over
- IPv6.
-
- Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
- IPv6-only hosts may not be configured with a DNS server. Where there
- is no DNS server authoritative for the name of a host or the
- authoritative DNS server does not support dynamic client update over
- IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
- be able to do DNS dynamic update, and other hosts will not be able to
- resolve its name.
-
- For example, if the configured DNS server responds to a AAAA RR query
- sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
- RCODE=0 and an empty answer section, then a AAAA RR query sent using
- LLMNR over IPv6 may be successful in resolving the name of an
- IPv6-only host on the local link.
-
- Similarly, if a DHCPv4 server is available providing DNS server
- configuration, and DNS server(s) exist which are authoritative for
- the A RRs of local hosts and support either dynamic client update
- over IPv4 or DHCPv4-based dynamic update, then the names of local
- IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
- DNS server is authoritative for the names of local hosts, or the
- authoritative DNS server(s) do not support dynamic update, then LLMNR
- enables linklocal name resolution over IPv4.
-
- Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
- configure LLMNR on an interface. The LLMNR Enable Option, described
- in [LLMNREnable], can be used to explicitly enable or disable use of
- LLMNR on an interface. The LLMNR Enable Option does not determine
- whether or in which order DNS itself is used for name resolution.
- The order in which various name resolution mechanisms should be used
- can be specified using the Name Service Search Option (NSSO) for DHCP
- [RFC2937], using the LLMNR Enable Option code carried in the NSSO
- data.
-
- It is possible that DNS configuration mechanisms will go in and out
- of service. In these circumstances, it is possible for hosts within
- an administrative domain to be inconsistent in their DNS
- configuration.
-
- For example, where DHCP is used for configuring DNS servers, one or
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- more DHCP servers can fail. As a result, hosts configured prior to
- the outage will be configured with a DNS server, while hosts
- configured after the outage will not. Alternatively, it is possible
- for the DNS configuration mechanism to continue functioning while
- configured DNS servers fail.
-
- An outage in the DNS configuration mechanism may result in hosts
- continuing to use LLMNR even once the outage is repaired. Since
- LLMNR only enables linklocal name resolution, this represents a
- degradation in capabilities. As a result, hosts without a configured
- DNS server may wish to periodically attempt to obtain DNS
- configuration if permitted by the configuration mechanism in use. In
- the absence of other guidance, a default retry interval of one (1)
- minute is RECOMMENDED.
-
-4. Conflict Resolution
-
- By default, a responder SHOULD be configured to behave as though its
- name is UNIQUE on each interface on which LLMNR is enabled. However,
- it is also possible to configure multiple responders to be
- authoritative for the same name. For example, multiple responders
- MAY respond to a query for an A or AAAA type record for a cluster
- name (assigned to multiple hosts in the cluster).
-
- To detect duplicate use of a name, an administrator can use a name
- resolution utility which employs LLMNR and lists both responses and
- responders. This would allow an administrator to diagnose behavior
- and potentially to intervene and reconfigure LLMNR responders who
- should not be configured to respond to the same name.
-
-4.1. Uniqueness Verification
-
- Prior to sending an LLMNR response with the 'T' bit clear, a
- responder configured with a UNIQUE name MUST verify that there is no
- other host within the scope of LLMNR query propagation that is
- authoritative for the same name on that interface.
-
- Once a responder has verified that its name is UNIQUE, if it receives
- an LLMNR query for that name, with the 'C' bit clear, it MUST
- respond, with the 'T' bit clear. Prior to verifying that its name is
- UNIQUE, a responder MUST set the 'T' bit in responses.
-
- Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive
- during sleep)
- - is configured to respond to LLMNR queries on an interface
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- enabled for transmission and reception of IP traffic
- - is configured to respond to LLMNR queries using additional
- UNIQUE resource records
- - verifies the acquisition of a new IP address and configuration
- on an interface
-
- To verify uniqueness, a responder MUST send an LLMNR query with the
- 'C' bit clear, over all protocols on which it responds to LLMNR
- queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
- uniqueness of a name by sending a query for the name with type='ANY'.
-
- If no response is received, the sender retransmits the query, as
- specified in Section 2.7. If a response is received, the sender MUST
- check if the source address matches the address of any of its
- interfaces; if so, then the response is not considered a conflict,
- since it originates from the sender. To avoid triggering conflict
- detection, a responder that detects that it is connected to the same
- link on multiple interfaces SHOULD set the 'C' bit in responses.
-
- If a response is received with the 'T' bit clear, the responder MUST
- NOT use the name in response to LLMNR queries received over any
- protocol (IPv4 or IPv6). If a response is received with the 'T' bit
- set, the responder MUST check if the source IP address in the
- response, interpreted as an unsigned integer, is less than the source
- IP address in the query. If so, the responder MUST NOT use the name
- in response to LLMNR queries received over any protocol (IPv4 or
- IPv6). For the purpose of uniqueness verification, the contents of
- the answer section in a response is irrelevant.
-
- Periodically carrying out uniqueness verification in an attempt to
- detect name conflicts is not necessary, wastes network bandwidth, and
- may actually be detrimental. For example, if network links are
- joined only briefly, and are separated again before any new
- communication is initiated, temporary conflicts are benign and no
- forced reconfiguration is required. LLMNR responders SHOULD NOT
- periodically attempt uniqueness verification.
-
-4.2. Conflict Detection and Defense
-
- Hosts on disjoint network links may configure the same name for use
- with LLMNR. If these separate network links are later joined or
- bridged together, then there may be multiple hosts which are now on
- the same link, trying to use the same name.
-
- In order to enable ongoing detection of name conflicts, when an LLMNR
- sender receives multiple LLMNR responses to a query, it MUST check if
- the 'C' bit is clear in any of the responses. If so, the sender
- SHOULD send another query for the same name, type and class, this
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- time with the 'C' bit set, with the potentially conflicting resource
- records included in the additional section.
-
- Queries with the 'C' bit set are considered advisory and responders
- MUST verify the existence of a conflict before acting on it. A
- responder receiving a query with the 'C' bit set MUST NOT respond.
-
- If the query is for a UNIQUE name, then the responder MUST send its
- own query for the same name, type and class, with the 'C' bit clear.
- If a response is received, the sender MUST check if the source
- address matches the address of any of its interfaces; if so, then the
- response is not considered a conflict, since it originates from the
- sender. To avoid triggering conflict detection, a responder that
- detects that it is connected to the same link on multiple interfaces
- SHOULD set the 'C' bit in responses.
-
- An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
- log them. Upon detecting a conflict, an LLMNR responder MUST
- immediately stop using the conflicting name in response to LLMNR
- queries received over any supported protocol, if the source IP
- address in the response, interpreted as an unsigned integer, is less
- than the source IP address in the uniqueness verification query.
-
- After stopping the use of a name, the responder MAY elect to
- configure a new name. However, since name reconfiguration may be
- disruptive, this is not required, and a responder may have been
- configured to respond to multiple names so that alternative names may
- already be available. A host that has stopped the use of a name may
- attempt uniqueness verification again after the expiration of the TTL
- of the conflicting response.
-
-4.3. Considerations for Multiple Interfaces
-
- A multi-homed host may elect to configure LLMNR on only one of its
- active interfaces. In many situations this will be adequate.
- However, should a host need to configure LLMNR on more than one of
- its active interfaces, there are some additional precautions it MUST
- take. Implementers who are not planning to support LLMNR on multiple
- interfaces simultaneously may skip this section.
-
- Where a host is configured to issue LLMNR queries on more than one
- interface, each interface maintains its own independent LLMNR
- resolver cache, containing the responses to LLMNR queries.
-
- A multi-homed host checks the uniqueness of UNIQUE records as
- described in Section 4. The situation is illustrated in figure 1.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
- In this situation, the multi-homed myhost will probe for, and defend,
- its host name on both interfaces. A conflict will be detected on one
- interface, but not the other. The multi-homed myhost will not be
- able to respond with a host RR for "myhost" on the interface on the
- right (see Figure 1). The multi-homed host may, however, be
- configured to use the "myhost" name on the interface on the left.
-
- Since names are only unique per-link, hosts on different links could
- be using the same name. If an LLMNR client sends requests over
- multiple interfaces, and receives replies from more than one, the
- result returned to the client is defined by the implementation. The
- situation is illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
- If host myhost is configured to use LLMNR on both interfaces, it will
- send LLMNR queries on both interfaces. When host myhost sends a
- query for the host RR for name "A" it will receive a response from
- hosts on both interfaces.
-
- Host myhost cannot distinguish between the situation shown in Figure
- 2, and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
- This illustrates that the proposed name conflict resolution mechanism
- does not support detection or resolution of conflicts between hosts
- on different links. This problem can also occur with DNS when a
- multi-homed host is connected to two different networks with
- separated name spaces. It is not the intent of this document to
- address the issue of uniqueness of names within DNS.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-4.4. API Issues
-
- [RFC2553] provides an API which can partially solve the name
- ambiguity problem for applications written to use this API, since the
- sockaddr_in6 structure exposes the scope within which each scoped
- address exists, and this structure can be used for both IPv4 (using
- v4-mapped IPv6 addresses) and IPv6 addresses.
-
- Following the example in Figure 2, an application on 'myhost' issues
- the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
- ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
- interfaces and the resolver library will return a list containing
- multiple addrinfo structures, each with an associated sockaddr_in6
- structure. This list will thus contain the IPv4 and IPv6 addresses
- of both hosts responding to the name 'A'. Link-local addresses will
- have a sin6_scope_id value that disambiguates which interface is used
- to reach the address. Of course, to the application, Figures 2 and 3
- are still indistinguishable, but this API allows the application to
- communicate successfully with any address in the list.
-
-5. Security Considerations
-
- LLMNR is a peer-to-peer name resolution protocol designed for use on
- the local link. While LLMNR limits the vulnerability of responders
- to off-link senders, it is possible for an off-link responder to
- reach a sender.
-
- In scenarios such as public "hotspots" attackers can be present on
- the same link. These threats are most serious in wireless networks
- such as 802.11, since attackers on a wired network will require
- physical access to the network, while wireless attackers may mount
- attacks from a distance. Link-layer security such as [IEEE-802.11i]
- can be of assistance against these threats if it is available.
-
- This section details security measures available to mitigate threats
- from on and off-link attackers.
-
-5.1. Denial of Service
-
- Attackers may take advantage of LLMNR conflict detection by
- allocating the same name, denying service to other LLMNR responders
- and possibly allowing an attacker to receive packets destined for
- other hosts. By logging conflicts, LLMNR responders can provide
- forensic evidence of these attacks.
-
- An attacker may spoof LLMNR queries from a victim's address in order
- to mount a denial of service attack. Responders setting the IPv6 Hop
- Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- response may be able to reach the victim across the Internet.
-
- While LLMNR responders only respond to queries for which they are
- authoritative and LLMNR does not provide wildcard query support, an
- LLMNR response may be larger than the query, and an attacker can
- generate multiple responses to a query for a name used by multiple
- responders. A sender may protect itself against unsolicited
- responses by silently discarding them as rapidly as possible.
-
-5.2. Spoofing
-
- LLMNR is designed to prevent reception of queries sent by an off-link
- attacker. LLMNR requires that responders receiving UDP queries check
- that they are sent to a link-scope multicast address. However, it is
- possible that some routers may not properly implement link-scope
- multicast, or that link-scope multicast addresses may leak into the
- multicast routing system. To prevent successful setup of TCP
- connections by an off-link sender, responders receiving a TCP SYN
- reply with a TCP SYN-ACK with TTL set to one (1).
-
- While it is difficult for an off-link attacker to send an LLMNR query
- to a responder, it is possible for an off-link attacker to spoof a
- response to a query (such as an A or AAAA query for a popular
- Internet host), and by using a TTL or Hop Limit field larger than one
- (1), for the forged response to reach the LLMNR sender. Since the
- forged response will only be accepted if it contains a matching ID
- field, choosing a pseudo-random ID field within queries provides some
- protection against off-link responders.
-
- Since LLMNR queries can be sent when DNS server(s) do not respond, an
- attacker can execute a denial of service attack on the DNS server(s)
- and then poison the LLMNR cache by responding to an LLMNR query with
- incorrect information. As noted in "Threat Analysis of the Domain
- Name System (DNS)" [RFC3833] these threats also exist with DNS, since
- DNS response spoofing tools are available that can allow an attacker
- to respond to a query more quickly than a distant DNS server.
- However, while switched networks or link layer security may make it
- difficult for an on-link attacker to snoop unicast DNS queries,
- multicast LLMNR queries are propagated to all hosts on the link,
- making it possible for an on-link attacker to spoof LLMNR responses
- without having to guess the value of the ID field in the query.
-
- Since LLMNR queries are sent and responded to on the local-link, an
- attacker will need to respond more quickly to provide its own
- response prior to arrival of the response from a legitimate
- responder. If an LLMNR query is sent for an off-link host, spoofing
- a response in a timely way is not difficult, since a legitimate
- response will never be received.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- This vulnerability can be reduced by limiting use of LLMNR to
- resolution of single-label names as described in Section 3, or by
- implementation of authentication (see Section 5.3).
-
-5.3. Authentication
-
- LLMNR is a peer-to-peer name resolution protocol, and as a result,
- it is often deployed in situations where no trust model can be
- assumed. Where a pre-arranged security configuration is possible,
- the following security mechanisms may be used:
-
-[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
- [RFC2931] security mechanisms. "DNS Name Service based on Secure
- Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
- the use of TSIG to secure LLMNR, based on group keys. While group
- keys can be used to demonstrate membership in a group, they do not
- protect against forgery by an attacker that is a member of the
- group.
-
-[b] IPsec ESP with a null-transform MAY be used to authenticate unicast
- LLMNR queries and responses or LLMNR responses to multicast
- queries. In a small network without a certificate authority, this
- can be most easily accomplished through configuration of a group
- pre-shared key for trusted hosts. As with TSIG, this does not
- protect against forgery by an attacker with access to the group
- pre-shared key.
-
-[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to
- support DNSSEC, LLMNR implementations MAY be configured with trust
- anchors, or they MAY make use of keys obtained from DNS queries.
- Since LLMNR does not support "delegated trust" (CD or AD bits),
- LLMNR implementations cannot make use of DNSSEC unless they are
- DNSSEC-aware and support validation. Unlike approaches [a] or [b],
- DNSSEC permits a responder to demonstrate ownership of a name, not
- just membership within a trusted group. As a result, it enables
- protection against forgery.
-
-5.4. Cache and Port Separation
-
- In order to prevent responses to LLMNR queries from polluting the DNS
- cache, LLMNR implementations MUST use a distinct, isolated cache for
- LLMNR on each interface. The use of separate caches is most
- effective when LLMNR is used as a name resolution mechanism of last
- resort, since this minimizes the opportunities for poisoning the
- LLMNR cache, and decreases reliance on it.
-
- LLMNR operates on a separate port from DNS, reducing the likelihood
- that a DNS server will unintentionally respond to an LLMNR query.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- If LLMNR is given higher priority than DNS among the enabled name
- resolution mechanisms, a denial of service attack on the DNS server
- would not be necessary in order to poison the LLMNR cache, since
- LLMNR queries would be sent even when the DNS server is available.
- In addition, the LLMNR cache, once poisoned, would take precedence
- over the DNS cache, eliminating the benefits of cache separation. As
- a result, LLMNR SHOULD NOT be used as a primary name resolution
- mechanism.
-
-6. IANA Considerations
-
- LLMNR requires allocation of port 5355 for both TCP and UDP.
-
- LLMNR requires allocation of link-scope multicast IPv4 address
- 224.0.0.252, as well as link-scope multicast IPv6 address
- FF02:0:0:0:0:0:1:3.
-
- This specification creates two new name spaces: the LLMNR namespace
- and the reserved bits in the LLMNR header. The reserved bits in the
- LLMNR header are allocated by IETF Consensus, in accordance with BCP
- 26 [RFC2434].
-
- In order to to avoid creating any new administrative procedures,
- administration of the LLMNR namespace will piggyback on the
- administration of the DNS namespace.
-
- The rights to use a fully qualified domain name (FQDN) within LLMNR
- are obtained coincident with acquiring the rights to use that name
- within DNS. Those wishing to use a FQDN within LLMNR should first
- acquire the rights to use the corresponding FQDN within DNS. Using a
- FQDN within LLMNR without ownership of the corresponding name in DNS
- creates the possibility of conflict and therefore is discouraged.
-
- LLMNR responders may self-allocate a name within the single-label
- name space, first defined in [RFC1001]. Since single-label names are
- not unique, no registration process is required.
-
-7. Constants
-
- The following timing constants are used in this protocol; they are
- not intended to be user configurable.
-
- JITTER_INTERVAL 100 ms
- LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
- 100 ms (IEEE 802 media, including IEEE 802.11)
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-8. References
-
-8.1. Normative References
-
-[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS
- Service on a TCP/UDP Transport: Concepts and Methods", RFC
- 1001, March 1987.
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
-[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.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
-8.2. Informative References
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
- Caching", IEEE/ACM Transactions on Networking, Volume 10,
- Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- Internet draft (work in progress), draft-ietf-ipv6-dns-
- discovery-07.txt, October 2002.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 26]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[IEEE-802.11i]
- Institute of Electrical and Electronics Engineers, "Supplement
- to Standard for Telecommunications and Information Exchange
- Between Systems - LAN/MAN Specific Requirements - Part 11:
- Wireless LAN Medium Access Control (MAC) and Physical Layer
- (PHY) Specifications: Specification for Enhanced Security",
- IEEE 802.11i, July 2004.
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
- Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
- Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
- 2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 27]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirement", RFC 4033, March
- 2005.
-
-Acknowledgments
-
- This work builds upon original work done on multicast DNS by Bill
- Manning and Bill Woodcock. Bill Manning's work was funded under
- DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
- their contribution to the current specification. Constructive input
- has also been received from Mark Andrews, Rob Austein, Randy Bush,
- Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
- Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
- Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
- Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
- St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 706 6605
- EMail: bernarda@microsoft.com
-
- Dave Thaler
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 703 8835
- EMail: dthaler@microsoft.com
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 28]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 29]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 30]
-
-
-
+++ /dev/null
-
-INTERNET-DRAFT DSA Information in the DNS
-OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
- DSA Keying and Signature Information in the DNS
- --- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
- The standard method of encoding US Government Digital Signature
- Algorithm keying and signature information for use in the Domain Name
- System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DSA Keying Information..................................3
- 3. DSA Signature Information...............................4
- 4. Performance Considerations..............................4
- 5. Security Considerations.................................5
- 6. IANA Considerations.....................................5
- Copyright, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative References.....................................7
-
- Author's Address...........................................8
- Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additional work is underway which would
- require the storage of keying and signature information in the DNS.
-
- This document describes how to encode US Government Digital Signature
- Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
- US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
- When DSA public keys are stored in the DNS, the structure of the
- relevant part of the RDATA part of the RR being used is the fields
- listed below in the order given.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- Field Size
- ----- ----
- T 1 octet
- Q 20 octets
- P 64 + T*8 octets
- G 64 + T*8 octets
- Y 64 + T*8 octets
-
- As described in [FIPS 186-2] and [Schneier], T is a key size
- parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
- is greater than 8 is reserved and the remainder of the data may have
- a different format in that case.) Q is a prime number selected at
- key generation time such that 2**159 < Q < 2**160. Thus Q is always
- 20 octets long and, as with all other fields, is stored in "big-
- endian" network order. P, G, and Y are calculated as directed by the
- [FIPS 186-2] key generation algorithm [Schneier]. P is in the range
- 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
- and Y are quantities modulo P and so can be up to the same length as
- P and are allocated fixed size fields with the same number of octets
- as P.
-
- During the key generation process, a random number X must be
- generated such that 1 <= X <= Q-1. X is the private key and is used
- in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
- The portion of the RDATA area used for US Digital Signature Algorithm
- signature information is shown below with fields in the order they
- are listed and the contents of each multi-octet field in "big-endian"
- network order.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- First, the data signed must be determined. Then the following steps
- are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
- specified in the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate a random K such that 0 < K < Q.
-
- R = ( G**K mod P ) mod Q
-
- S = ( K**(-1) * (hash + X*R) ) mod Q
-
- For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
- 3174].
-
- Since Q is 160 bits long, R and S can not be larger than 20 octets,
- which is the space allocated.
-
- T is copied from the public key. It is not logically necessary in
- the SIG but is present so that values of T > 8 can more conveniently
- be used as an escape for extended versions of DSA or other algorithms
- as later standardized.
-
-
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA [RFC
- 3110] and DSA. With sufficient pre-computation, signature generation
- with DSA is faster than RSA. Key generation is also faster for DSA.
- However, signature verification is an order of magnitude slower than
- RSA when the RSA public exponent is chosen to be small, as is
- recommended for some applications.
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying and/or signature
- inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
- current DSA standard may limit the security of DSA. For particular
- applications, implementors are encouraged to consider the range of
- available algorithms and key sizes.
-
- DSA assumes the ability to frequently generate high quality random
- numbers. See [random] for guidance. DSA is designed so that if
- biased rather than random numbers are used, high bandwidth covert
- channels are possible. See [Schneier] and more recent research. The
- leakage of an entire DSA private key in only two DSA signatures has
- been demonstrated. DSA provides security only if trusted
- implementations, including trusted random number generation, are
- used.
-
-
-
-6. IANA Considerations
-
- Allocation of meaning to values of the T parameter that are not
- defined herein (i.e., > 8 ) requires an IETF standards actions. It
- is intended that values unallocated herein be used to cover future
- extensions of the DSS standard.
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Normative References
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, 27 January 2000.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative References
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, 11/01/1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, 11/01/1987.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS)", D. Eastlake 3rd. May 2001.
-
- [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
- Jones, September 2001.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [Schneier] - "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C" (second edition), Bruce Schneier,
- 1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Labortories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554(w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2006.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
-
-
- Storage of Diffie-Hellman Keying Information in the DNS
- ------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
-
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for encoding Diffie-Hellman keys in the Domain
- Name System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
- Part of the format for Diffie-Hellman keys and the description
- thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
- and Hemma Prafullchandra. In addition, the following persons
- provided useful comments that were incorporated into the predecessor
- of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 1.1 About This Document....................................3
- 1.2 About Diffie-Hellman...................................3
- 2. Encoding Diffie-Hellman Keying Information..............4
- 3. Performance Considerations..............................5
- 4. IANA Considerations.....................................5
- 5. Security Considerations.................................5
- Copyright, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative Refences.......................................7
-
- Author's Address...........................................8
- Expiration and File Name...................................8
-
- Appendix A: Well known prime/generator pairs...............9
- A.1. Well-Known Group 1: A 768 bit prime..................9
- A.2. Well-Known Group 2: A 1024 bit prime.................9
- A.3. Well-Known Group 3: A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- similar information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additonal work is underway which would use
- the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
- This document describes how to store Diffie-Hellman keys in the DNS.
- Familiarity with the Diffie-Hellman key exchange algorithm is assumed
- [Schneier, RFC 2631].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119.
-
-
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Thus Diffie-
- Hellman is inherently a key agreement algorithm. As a result, no
- format is defined for Diffie-Hellman "signature information". For
- example, assume that two parties have local secrets "i" and "j".
- Assume they each respectively calculate X and Y as follows:
-
- X = g**i ( mod p )
-
- Y = g**j ( mod p )
-
- They exchange these quantities and then each calculates a Z as
- follows:
-
- Zi = Y**i ( mod p )
-
- Zj = X**j ( mod p )
-
- Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
- secret between the two parties that an adversary who does not know i
- or j will not be able to learn from the exchanged messages (unless
- the adversary can derive i or j by performing a discrete logarithm
- mod p which is hard for strong p and g).
-
- The private key for each party is their secret i (or j). The public
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- key is the pair p and g, which is the same for both parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
- in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
- When Diffie-Hellman keys appear within the RDATA portion of a RR,
- they are encoded as shown below.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | KEY flags | protocol | algorithm=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | prime length (or flag) | prime (p) (or special) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / prime (p) (variable length) | generator length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | generator (g) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | public value length | public value (variable length)/
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / public value (g^i mod p) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Prime length is the length of the Diffie-Hellman prime (p) in bytes
- if it is 16 or greater. Prime contains the binary representation of
- the Diffie-Hellman prime with most significant byte first (i.e., in
- network order). If "prime length" field is 1 or 2, then the "prime"
- field is actually an unsigned index into a table of 65,536
- prime/generator pairs and the generator length SHOULD be zero. See
- Appedix A for defined table entries and Section 4 for information on
- allocating additional table entries. The meaning of a zero or 3
- through 15 value for "prime length" is reserved.
-
- Generator length is the length of the generator (g) in bytes.
- Generator is the binary representation of generator with most
- significant byte first. PublicValueLen is the Length of the Public
- Value (g**i (mod p)) in bytes. PublicValue is the binary
- representation of the DH public value with most significant byte
- first.
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient. But
- it is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying information consistent
- with adequate security.
-
-
-
-4. IANA Considerations
-
- Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
- an IETF consensus as defined in [RFC 2434].
-
- Well known prime/generator pairs number 0x0000 through 0x07FF can
- only be assigned by an IETF standards action. [RFC 2539], the
- Proposed Standard predecessor of this document, assigned 0x0001
- through 0x0002. This document additionally assigns 0x0003. Pairs
- number 0s0800 through 0xBFFF can be assigned based on RFC
- documentation. Pairs number 0xC000 through 0xFFFF are available for
- private use and are not centrally coordinated. Use of such private
- pairs outside of a closed environment may result in conflicts and/or
- security failures.
-
-
-
-5. Security Considerations
-
- Keying information retrieved from the DNS should not be trusted
- unless (1) it has been securely obtained from a secure resolver or
- independently verified by the user and (2) this secure resolver and
- secure obtainment or independent verification conform to security
- policies acceptable to the user. As with all cryptographic
- algorithms, evaluating the necessary strength of the key is important
- and dependent on security policy.
-
- In addition, the usual Diffie-Hellman key strength considerations
- apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
- SHOULD be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Normative References
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
- in RFCs", T. Narten, H. Alvestrand, October 1998.
-
- [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
- 1999.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative Refences
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, November 1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, November 1987.
-
- [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
- and Sons.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2006.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
- These numbers are copied from the IPSEC effort where the derivation
- of these values is more fully explained and additional information is
- available. Richard Schroeppel performed all the mathematical and
- computational work for this appendix.
-
-
-
-A.1. Well-Known Group 1: A 768 bit prime
-
- The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
- decimal value is
- 155251809230070893513091813125848175563133404943451431320235
- 119490296623994910210725866945387659164244291000768028886422
- 915080371891804634263272761303128298374438082089019628850917
- 0691316593175367469551763119843371637221007210577919
-
- Prime modulus: Length (32 bit words): 24, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2: A 1024 bit prime
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its decimal value is
- 179769313486231590770839156793787453197860296048756011706444
- 423684197180216158519368947833795864925541502180565485980503
- 646440548199239100050792877003355816639229553136239076508735
- 759914822574862575007425302077447712589550957937778424442426
- 617334727629299387668709205606050270810842907692932019128194
- 467627007
-
- Prime modulus: Length (32 bit words): 32, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
- FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3: A 1536 bit prime
-
- The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
- Its decimal value is
- 241031242692103258855207602219756607485695054850245994265411
- 694195810883168261222889009385826134161467322714147790401219
- 650364895705058263194273070680500922306273474534107340669624
- 601458936165977404102716924945320037872943417032584377865919
- 814376319377685986952408894019557734611984354530154704374720
- 774996976375008430892633929555996888245787241299381012913029
- 459299994792636526405928464720973038494721168143446471443848
- 8520940127459844288859336526896320919633919
-
- Prime modulus Length (32 bit words): 48, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
- C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
- 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
- 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Paul Vixie, ISC
-INTERNET-DRAFT
-<draft-ietf-dnsext-rfc2671bis-edns0-01.txt> March 17, 2008
-
-Intended Status: Standards Track
-Obsoletes: 2671 (if approved)
-
-
- Revised extension mechanisms for DNS (EDNS0)
-
-
-Status of this Memo
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-
- Abstract
-
- The Domain Name System's wire protocol includes a number of fixed
- fields whose range has been or soon will be exhausted and does not
- allow clients to advertise their capabilities to servers. This
- document describes backward compatible mechanisms for allowing the
- protocol to grow.
-
-
-
-Expires September 2008 [Page 1]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-1 - Introduction
-
-1.1. DNS (see [RFC1035]) specifies a Message Format and within such
-messages there are standard formats for encoding options, errors, and
-name compression. The maximum allowable size of a DNS Message is fixed.
-Many of DNS's protocol limits are too small for uses which are or which
-are desired to become common. There is no way for implementations to
-advertise their capabilities.
-
-1.2. Unextended agents will not know how to interpret the protocol
-extensions detailed here. In practice, these clients will be upgraded
-when they have need of a new feature, and only new features will make
-use of the extensions. Extended agents must be prepared for behaviour
-of unextended clients in the face of new protocol elements, and fall
-back gracefully to unextended DNS. RFC 2671 originally has proposed
-extensions to the basic DNS protocol to overcome these deficiencies.
-This memo refines that specification and obsoletes RFC 2671.
-
-1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [RFC2119].
-
-2 - Affected Protocol Elements
-
-2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
-word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
-1-bit flags. The original reserved Z bits have been allocated to
-various purposes, and most of the RCODE values are now in use. More
-flags and more possible RCODEs are needed. The OPT pseudo-RR specified
-in Section 4 contains subfields that carry a bit field extension of the
-RCODE field and additional flag bits, respectively; for details see
-Section 4.6 below.
-
-2.2. The first two bits of a wire format domain label are used to denote
-the type of the label. [RFC1035 4.1.4] allocates two of the four
-possible types and reserves the other two. Proposals for use of the
-remaining types far outnumber those available. More label types were
-needed, and an extension mechanism was proposed in RFC 2671 [RFC2671
-Section 3]. Section 3 of this document reserves DNS labels with a first
-octet in the range of 64-127 decimal (label type 01) for future
-standardization of Extended DNS Labels.
-
-
-
-
-
-
-
-Expires September 2008 [Page 2]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
-While the minimum maximum reassembly buffer size still allows a limit of
-512 octets of UDP payload, most of the hosts now connected to the
-Internet are able to reassemble larger datagrams. Some mechanism must
-be created to allow requestors to advertise larger buffer sizes to
-responders. To this end, the OPT pseudo-RR specified in Section 4
-contains a maximum payload size field; for details see Section 4.5
-below.
-
-3 - Extended Label Types
-
-The first octet in the on-the-wire representation of a DNS label
-specifies the label type; the basic DNS specification [RFC1035]
-dedicates the two most significant bits of that octet for this purpose.
-
-This document reserves DNS label type 0b01 for use as an indication for
-Extended Label Types. A specific extended label type is selected by the
-6 least significant bits of the first octet. Thus, Extended Label Types
-are indicated by the values 64-127 (0b01xxxxxx) in the first octet of
-the label.
-
-Allocations from this range are to be made for IETF documents fully
-describing the syntax and semantics as well as the applicability of the
-particular Extended Label Type.
-
-This document does not describe any specific Extended Label Type.
-
-4 - OPT pseudo-RR
-
-4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data
-section of a request, and to responses to such requests. An OPT is
-called a pseudo-RR because it pertains to a particular transport level
-message and not to any actual DNS data. OPT RRs MUST NOT be cached,
-forwarded, or stored in or loaded from master files. The quantity of
-OPT pseudo-RRs per message MUST be either zero or one, but not greater.
-
-4.2. An OPT RR has a fixed part and a variable set of options expressed
-as {attribute, value} pairs. The fixed part holds some DNS meta data
-and also a small collection of new protocol elements which we expect to
-be so popular that it would be a waste of wire space to encode them as
-{attribute, value} pairs.
-
-
-
-
-
-
-
-Expires September 2008 [Page 3]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-4.3. The fixed part of an OPT RR is structured as follows:
-
-Field Name Field Type Description
-------------------------------------------------------
-NAME domain name empty (root domain)
-TYPE u_int16_t OPT (41)
-CLASS u_int16_t sender's UDP payload size
-TTL u_int32_t extended RCODE and flags
-RDLEN u_int16_t describes RDATA
-RDATA octet stream {attribute,value} pairs
-
-
-4.4. The variable part of an OPT RR is encoded in its RDATA and is
-structured as zero or more of the following:
-
- : +0 (MSB) : +1 (LSB) :
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 0: | OPTION-CODE |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 2: | OPTION-LENGTH |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 4: | |
- / OPTION-DATA /
- / /
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-OPTION-CODE (Assigned by IANA.)
-
-OPTION-LENGTH Size (in octets) of OPTION-DATA.
-
-OPTION-DATA Varies per OPTION-CODE.
-
-4.4.1. Order of appearance of option tuples is never relevant. Any
-option whose meaning is affected by other options is so affected no
-matter which one comes first in the OPT RDATA.
-
-4.4.2. Any OPTION-CODE values not understood by a responder or requestor
-MUST be ignored. So, specifications of such options might wish to
-include some kind of signalled acknowledgement. For example, an option
-specification might say that if a responder sees option XYZ, it SHOULD
-include option XYZ in its response.
-
-
-
-
-
-
-Expires September 2008 [Page 4]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
-field) is the number of octets of the largest UDP payload that can be
-reassembled and delivered in the sender's network stack. Note that path
-MTU, with or without fragmentation, may be smaller than this. Values
-lower than 512 are undefined, and may be treated as format errors, or
-may be treated as equal to 512, at the implementor's discretion.
-
-4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
-reassembly buffer. Choosing 1280 on an Ethernet connected requestor
-would be reasonable. The consequence of choosing too large a value may
-be an ICMP message from an intermediate gateway, or even a silent drop
-of the response message.
-
-4.5.2. Both requestors and responders are advised to take account of the
-path's discovered MTU (if already known) when considering message sizes.
-
-4.5.3. The requestor's maximum payload size can change over time, and
-therefore MUST NOT be cached for use beyond the transaction in which it
-is advertised.
-
-4.5.4. The responder's maximum payload size can change over time, but
-can be reasonably expected to remain constant between two sequential
-transactions; for example, a meaningless QUERY to discover a responder's
-maximum UDP payload size, followed immediately by an UPDATE which takes
-advantage of this size. (This is considered preferrable to the outright
-use of TCP for oversized requests, if there is any reason to suspect
-that the responder implements EDNS, and if a request will not fit in the
-default 512 payload size limit.)
-
-4.5.5. Due to transaction overhead, it is unwise to advertise an
-architectural limit as a maximum UDP payload size. Just because your
-stack can reassemble 64KB datagrams, don't assume that you want to spend
-more than about 4KB of state memory per ongoing transaction.
-
-4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
-are structured as follows:
-
- : +0 (MSB) : +1 (LSB) :
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 0: | EXTENDED-RCODE | VERSION |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 2: | DO| Z |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-
-
-
-Expires September 2008 [Page 5]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that
- EXTENDED-RCODE value zero (0) indicates that an
- unextended RCODE is in use (values zero (0) through
- fifteen (15)).
-
-VERSION Indicates the implementation level of whoever sets it.
- Full conformance with this specification is indicated by
- version zero (0). Requestors are encouraged to set this
- to the lowest implemented level capable of expressing a
- transaction, to minimize the responder and network load
- of discovering the greatest common implementation level
- between requestor and responder. A requestor's version
- numbering strategy should ideally be a run time
- configuration option.
-
- If a responder does not implement the VERSION level of
- the request, then it answers with RCODE=BADVERS. All
- responses MUST be limited in format to the VERSION level
- of the request, but the VERSION of each response MUST be
- the highest implementation level of the responder. In
- this way a requestor will learn the implementation level
- of a responder as a side effect of every response,
- including error responses, including RCODE=BADVERS.
-
-DO DNSSEC OK bit [RFC3225].
-
-Z Set to zero by senders and ignored by receivers, unless
- modified in a subsequent specification [IANAFLAGS].
-
-5 - Transport Considerations
-
-5.1. The presence of an OPT pseudo-RR in a request is an indication that
-the requestor fully implements the given version of EDNS, and can
-correctly understand any response that conforms to that feature's
-specification.
-
-5.2. Lack of use of these features in a request is an indication that
-the requestor does not implement any part of this specification and that
-the responder SHOULD NOT use any protocol extension described here in
-its response.
-
-5.3. Responders who do not understand these protocol extensions are
-expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or
-to appear to "time out" due to inappropriate action by a "middle box"
-such as a NAT, or to ignore extensions and respond only to unextended
-
-
-
-Expires September 2008 [Page 6]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-protocol elements. Therefore use of extensions SHOULD be "probed" such
-that a responder who isn't known to support them be allowed a retry with
-no extensions if it responds with such an RCODE, or does not respond.
-If a responder's capability level is cached by a requestor, a new probe
-SHOULD be sent periodically to test for changes to responder capability.
-
-5.4. If EDNS is used in a request, and the response arrives with TC set
-and with no EDNS OPT RR, a requestor should assume that truncation
-prevented the OPT RR from being appended by the responder, and further,
-that EDNS is not used in the response. Correspondingly, an EDNS
-responder who cannot fit all necessary elements (including an OPT RR)
-into a response, should respond with a normal (unextended) DNS response,
-possibly setting TC if the response will not fit in the unextended
-response message's 512-octet size.
-
-6 - Security Considerations
-
-Requestor-side specification of the maximum buffer size may open a new
-DNS denial of service attack if responders can be made to send messages
-which are too large for intermediate gateways to forward, thus leading
-to potential ICMP storms between gateways and responders.
-
-7 - IANA Considerations
-
-IANA has allocated RR type code 41 for OPT.
-
-This document controls the following IANA sub-registries in registry
-"DOMAIN NAME SYSTEM PARAMETERS":
-
- "EDNS Extended Label Type"
- "EDNS Option Codes"
- "EDNS Version Numbers"
- "Domain System Response Code"
-
-IANA is advised to re-parent these subregistries to this document.
-
-This document assigns label type 0b01xxxxxx as "EDNS Extended Label
-Type." We request that IANA record this assignment.
-
-This document assigns option code 65535 to "Reserved for future
-expansion."
-
-This document assigns EDNS Extended RCODE "16" to "BADVERS".
-
-
-
-
-
-Expires September 2008 [Page 7]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-IESG approval is required to create new entries in the EDNS Extended
-Label Type or EDNS Version Number registries, while any published RFC
-(including Informational, Experimental, or BCP) is grounds for
-allocation of an EDNS Option Code.
-
-8 - Acknowledgements
-
-Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
-Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten,
-Alfred Hoenes and Markku Savela were each instrumental in creating and
-refining this specification.
-
-9 - References
-
-[RFC1035] P. Mockapetris, "Domain Names - Implementation and
- Specification," RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels," RFC 2119, Harvard University, March
- 1997.
-
-[RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671,
- Internet Software Consortium, August 1999.
-
-[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC
- 3225, Nominum Inc., December 2001.
-
-[IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site
- http://www.iana.org/assignments/dns-header-flags, as of
- June 2005 or later.
-
-10 - Author's Address
-
-Paul Vixie
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 423 1301
- EMail: vixie@isc.org
-
-
-
-
-
-
-
-
-Expires September 2008 [Page 8]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-Full Copyright Statement
-
-Copyright (C) IETF Trust (2007).
-
-This document is subject to the rights, licenses and restrictions
-contained in BCP 78, and except as set forth therein, the authors retain
-all their rights.
-
-This document and the information contained herein are provided on an
-"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
-IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE
-INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-The IETF takes no position regarding the validity or scope of any
-Intellectual Property Rights or other rights that might be claimed to
-pertain to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; nor does it represent that it has made any
-independent effort to identify any such rights. Information on the
-procedures with respect to rights in RFC documents can be found in BCP
-78 and BCP 79.
-
-Copies of IPR disclosures made to the IETF Secretariat and any
-assurances of licenses to be made available, or the result of an attempt
-made to obtain a general license or permission for the use of such
-proprietary rights by implementers or users of this specification can be
-obtained from the IETF on-line IPR repository at
-http://www.ietf.org/ipr.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-that may cover technology that may be required to implement this
-standard. Please address the information to the IETF at
-ietf-ipr@ietf.org.
-
-Acknowledgement
-
-Funding for the RFC Editor function is provided by the IETF
-Administrative Support Activity (IASA).
-
-
-
-
-Expires September 2008 [Page 9]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-Network Working Group M. StJohns
-Internet-Draft Nominum, Inc.
-Intended status: Informational November 29, 2006
-Expires: June 2, 2007
-
-
- Automated Updates of DNSSEC Trust Anchors
- draft-ietf-dnsext-trustupdate-timers-05
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on June 2, 2007.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes a means for automated, authenticated and
- authorized updating of DNSSEC "trust anchors". The method provides
- protection against N-1 key compromises of N keys in the trust point
- key set. Based on the trust established by the presence of a current
- anchor, other anchors may be added at the same place in the
- hierarchy, and, ultimately, supplant the existing anchor(s).
-
- This mechanism will require changes to resolver management behavior
-
-
-
-StJohns Expires June 2, 2007 [Page 1]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- (but not resolver resolution behavior), and the addition of a single
- flag bit to the DNSKEY record.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
- 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
- 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
- 2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5
- 2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
- 2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
- 2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
- 2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6
- 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
- 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8
- 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9
- 6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9
- 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
- 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
- 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10
- 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
- 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
- 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11
- 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
- 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
- Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
- Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 2]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-1. Introduction
-
- As part of the reality of fielding DNSSEC (Domain Name System
- Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
- come to the realization that there will not be one signed name space,
- but rather islands of signed name space each originating from
- specific points (i.e. 'trust points') in the DNS tree. Each of those
- islands will be identified by the trust point name, and validated by
- at least one associated public key. For the purpose of this document
- we'll call the association of that name and a particular key a 'trust
- anchor'. A particular trust point can have more than one key
- designated as a trust anchor.
-
- For a DNSSEC-aware resolver to validate information in a DNSSEC
- protected branch of the hierarchy, it must have knowledge of a trust
- anchor applicable to that branch. It may also have more than one
- trust anchor for any given trust point. Under current rules, a chain
- of trust for DNSSEC-protected data that chains its way back to ANY
- known trust anchor is considered 'secure'.
-
- Because of the probable balkanization of the DNSSEC tree due to
- signing voids at key locations, a resolver may need to know literally
- thousands of trust anchors to perform its duties. (e.g. Consider an
- unsigned ".COM".) Requiring the owner of the resolver to manually
- manage this many relationships is problematic. It's even more
- problematic when considering the eventual requirement for key
- replacement/update for a given trust anchor. The mechanism described
- herein won't help with the initial configuration of the trust anchors
- in the resolvers, but should make trust point key replacement/
- rollover more viable.
-
- As mentioned above, this document describes a mechanism whereby a
- resolver can update the trust anchors for a given trust point, mainly
- without human intervention at the resolver. There are some corner
- cases discussed (e.g. multiple key compromise) that may require
- manual intervention, but they should be few and far between. This
- document DOES NOT discuss the general problem of the initial
- configuration of trust anchors for the resolver.
-
-1.1. Compliance Nomenclature
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14, [RFC2119].
-
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 3]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-2. Theory of Operation
-
- The general concept of this mechanism is that existing trust anchors
- can be used to authenticate new trust anchors at the same point in
- the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a
- DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section
- 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
- validated by an existing trust anchor, then the resolver can add the
- new key to its valid set of trust anchors for that trust point.
-
- There are some issues with this approach which need to be mitigated.
- For example, a compromise of one of the existing keys could allow an
- attacker to add their own 'valid' data. This implies a need for a
- method to revoke an existing key regardless of whether or not that
- key is compromised. As another example, assuming a single key
- compromise, we need to prevent an attacker from adding a new key and
- revoking all the other old keys.
-
-2.1. Revocation
-
- Assume two trust anchor keys A and B. Assume that B has been
- compromised. Without a specific revocation bit, B could invalidate A
- simply by sending out a signed trust point key set which didn't
- contain A. To fix this, we add a mechanism which requires knowledge
- of the private key of a DNSKEY to revoke that DNSKEY.
-
- A key is considered revoked when the resolver sees the key in a self-
- signed RRSet and the key has the REVOKE bit (see Section 7 below) set
- to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this
- key as a trust anchor or for any other purposes except validating the
- RRSIG it signed over the DNSKEY RRSet specifically for the purpose of
- validating the revocation. Unlike the 'Add' operation below,
- revocation is immediate and permanent upon receipt of a valid
- revocation at the resolver.
-
- A self-signed RRSet is a DNSKEY RRSet which contains the specific
- DNSKEY and for which there is a corresponding validated RRSIG record.
- It's not a special DNSKEY RRSet, just a way of describing the
- validation requirements for that RRSet.
-
- N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
- than one without the bit set. This affects the matching of a DNSKEY
- to DS records in the parent, or the fingerprint stored at a resolver
- used to configure a trust point.
-
- In the given example, the attacker could revoke B because it has
- knowledge of B's private key, but could not revoke A.
-
-
-
-
-StJohns Expires June 2, 2007 [Page 4]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-2.2. Add Hold-Down
-
- Assume two trust point keys A and B. Assume that B has been
- compromised. An attacker could generate and add a new trust anchor
- key - C (by adding C to the DNSKEY RRSet and signing it with B), and
- then invalidate the compromised key. This would result in both the
- attacker and owner being able to sign data in the zone and have it
- accepted as valid by resolvers.
-
- To mitigate but not completely solve this problem, we add a hold-down
- time to the addition of the trust anchor. When the resolver sees a
- new SEP key in a validated trust point DNSKEY RRSet, the resolver
- starts an acceptance timer, and remembers all the keys that validated
- the RRSet. If the resolver ever sees the DNSKEY RRSet without the
- new key but validly signed, it stops the acceptance process for that
- key and resets the acceptance timer. If all of the keys which were
- originally used to validate this key are revoked prior to the timer
- expiring, the resolver stops the acceptance process and resets the
- timer.
-
- Once the timer expires, the new key will be added as a trust anchor
- the next time the validated RRSet with the new key is seen at the
- resolver. The resolver MUST NOT treat the new key as a trust anchor
- until the hold down time expires AND it has retrieved and validated a
- DNSKEY RRSet after the hold down time which contains the new key.
-
- N.B.: Once the resolver has accepted a key as a trust anchor, the key
- MUST be considered a valid trust anchor by that resolver until
- explictly revoked as described above.
-
- In the given example, the zone owner can recover from a compromise by
- revoking B and adding a new key D and signing the DNSKEY RRSet with
- both A and B.
-
- The reason this does not completely solve the problem has to do with
- the distributed nature of DNS. The resolver only knows what it sees.
- A determined attacker who holds one compromised key could keep a
- single resolver from realizing that key had been compromised by
- intercepting 'real' data from the originating zone and substituting
- their own (e.g. using the example, signed only by B). This is no
- worse than the current situation assuming a compromised key.
-
-2.3. Active Refresh
-
- A resolver which has been configured for automatic update of keys
- from a particular trust point MUST query that trust point (e.g. do a
- lookup for the DNSKEY RRSet and related RRSIG records) no less often
- than the lesser of 15 days or half the original TTL for the DNSKEY
-
-
-
-StJohns Expires June 2, 2007 [Page 5]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- RRSet or half the RRSIG expiration interval and no more often than
- once per hour. The expiration interval is the amount of time from
- when the RRSIG was last retrieved until the expiration time in the
- RRSIG.
-
- If the query fails, the resolver MUST repeat the query until
- satisfied no more often than once an hour and no less often than the
- lesser of 1 day or 10% of the original TTL or 10% of the original
- expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
- origTTL, .1 * expireInterval)).
-
-2.4. Resolver Parameters
-
-2.4.1. Add Hold-Down Time
-
- The add hold-down time is 30 days or the expiration time of the
- original TTL of the first trust point DNSKEY RRSet which contained
- the new key, whichever is greater. This ensures that at least two
- validated DNSKEY RRSets which contain the new key MUST be seen by the
- resolver prior to the key's acceptance.
-
-2.4.2. Remove Hold-Down Time
-
- The remove hold-down time is 30 days. This parameter is solely a key
- management database bookeeping parameter. Failure to remove
- information about the state of defunct keys from the database will
- not adversely impact the security of this protocol, but may end up
- with a database cluttered with obsolete key information.
-
-2.4.3. Minimum Trust Anchors per Trust Point
-
- A compliant resolver MUST be able to manage at least five SEP keys
- per trust point.
-
-
-3. Changes to DNSKEY RDATA Wire Format
-
- Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE'
- flag. If this bit is set to '1', AND the resolver sees an
- RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
- consider this key permanently invalid for all purposes except for
- validating the revocation.
-
-
-4. State Table
-
- The most important thing to understand is the resolver's view of any
- key at a trust point. The following state table describes that view
-
-
-
-StJohns Expires June 2, 2007 [Page 6]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- at various points in the key's lifetime. The table is a normative
- part of this specification. The initial state of the key is 'Start'.
- The resolver's view of the state of the key changes as various events
- occur.
-
- This is the state of a trust point key as seen from the resolver.
- The column on the left indicates the current state. The header at
- the top shows the next state. The intersection of the two shows the
- event that will cause the state to transition from the current state
- to the next.
-
-
- NEXT STATE
- --------------------------------------------------
- FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
- ----------------------------------------------------------
- Start | |NewKey | | | | |
- ----------------------------------------------------------
- AddPend |KeyRem | |AddTime| | |
- ----------------------------------------------------------
- Valid | | | |KeyRem |Revbit | |
- ----------------------------------------------------------
- Missing | | |KeyPres| |Revbit | |
- ----------------------------------------------------------
- Revoked | | | | | |RemTime|
- ----------------------------------------------------------
- Removed | | | | | | |
- ----------------------------------------------------------
-
-
- State Table
-
-4.1. Events
- NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
- That key will become a new trust anchor for the named trust point
- after it's been present in the RRSet for at least 'add time'.
- KeyPres The key has returned to the valid DNSKEY RRSet.
- KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
- this key.
- AddTime The key has been in every valid DNSKEY RRSet seen for at
- least the 'add time'.
- RemTime A revoked key has been missing from the trust point DNSKEY
- RRSet for sufficient time to be removed from the trust set.
- RevBit The key has appeared in the trust anchor DNSKEY RRSet with
- its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
- signed by this key.
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 7]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-4.2. States
- Start The key doesn't yet exist as a trust anchor at the resolver.
- It may or may not exist at the zone server, but either hasn't yet
- been seen at the resolver or was seen but was absent from the last
- DNSKEY RRSet (e.g. KeyRem event).
- AddPend The key has been seen at the resolver, has its 'SEP' bit
- set, and has been included in a validated DNSKEY RRSet. There is
- a hold-down time for the key before it can be used as a trust
- anchor.
- Valid The key has been seen at the resolver and has been included in
- all validated DNSKEY RRSets from the time it was first seen up
- through the hold-down time. It is now valid for verifying RRSets
- that arrive after the hold down time. Clarification: The DNSKEY
- RRSet does not need to be continuously present at the resolver
- (e.g. its TTL might expire). If the RRSet is seen, and is
- validated (i.e. verifies against an existing trust anchor), this
- key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
- Missing This is an abnormal state. The key remains as a valid trust
- point key, but was not seen at the resolver in the last validated
- DNSKEY RRSet. This is an abnormal state because the zone operator
- should be using the REVOKE bit prior to removal.
- Revoked This is the state a key moves to once the resolver sees an
- RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
- this key with its REVOKE bit set to '1'. Once in this state, this
- key MUST permanently be considered invalid as a trust anchor.
- Removed After a fairly long hold-down time, information about this
- key may be purged from the resolver. A key in the removed state
- MUST NOT be considered a valid trust anchor. (Note: this state is
- more or less equivalent to the "Start" state, except that it's bad
- practice to re-introduce previously used keys - think of this as
- the holding state for all the old keys for which the resolver no
- longer needs to track state.)
-
-
-5. Trust Point Deletion
-
- A trust point which has all of its trust anchors revoked is
- considered deleted and is treated as if the trust point was never
- configured. If there are no superior configured trust points, data
- at and below the deleted trust point are considered insecure by the
- resolver. If there ARE superior configured trust points, data at and
- below the deleted trust point are evaluated with respect to the
- superior trust point(s).
-
- Alternately, a trust point which is subordinate to another configured
- trust point MAY be deleted by a resolver after 180 days where such
- subordinate trust point validly chains to a superior trust point.
- The decision to delete the subordinate trust anchor is a local
-
-
-
-StJohns Expires June 2, 2007 [Page 8]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- configuration decision. Once the subordinate trust point is deleted,
- validation of the subordinate zone is dependent on validating the
- chain of trust to the superior trust point.
-
-
-6. Scenarios - Informative
-
- The suggested model for operation is to have one active key and one
- stand-by key at each trust point. The active key will be used to
- sign the DNSKEY RRSet. The stand-by key will not normally sign this
- RRSet, but the resolver will accept it as a trust anchor if/when it
- sees the signature on the trust point DNSKEY RRSet.
-
- Since the stand-by key is not in active signing use, the associated
- private key may (and should) be provided with additional protections
- not normally available to a key that must be used frequently. E.g.
- locked in a safe, split among many parties, etc. Notionally, the
- stand-by key should be less subject to compromise than an active key,
- but that will be dependent on operational concerns not addressed
- here.
-
-6.1. Adding a Trust Anchor
-
- Assume an existing trust anchor key 'A'.
- 1. Generate a new key pair.
- 2. Create a DNSKEY record from the key pair and set the SEP and Zone
- Key bits.
- 3. Add the DNSKEY to the RRSet.
- 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
- 'A'.
- 5. Wait a while (i.e. for various resolvers timers to go off and for
- them to retrieve the new DNSKEY RRSet and signatures).
- 6. The new trust anchor will be populated at the resolvers on the
- schedule described by the state table and update algorithm - see
- Section 2 above
-
-6.2. Deleting a Trust Anchor
-
- Assume existing trust anchors 'A' and 'B' and that you want to revoke
- and delete 'A'.
- 1. Set the revocation bit on key 'A'.
- 2. Sign the DNSKEY RRSet with both 'A' and 'B'.
- 'A' is now revoked. The operator should include the revoked 'A' in
- the RRSet for at least the remove hold-down time, but then may remove
- it from the DNSKEY RRSet.
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 9]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-6.3. Key Roll-Over
-
- Assume existing keys A and B. 'A' is actively in use (i.e. has been
- signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
- in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
- used to sign the RRSet.)
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'A'.
- 4. Sign the RRSet with 'A' and 'B'.
- 'A' is now revoked, 'B' is now the active key, and 'C' will be the
- stand-by key once the hold-down expires. The operator should include
- the revoked 'A' in the RRSet for at least the remove hold-down time,
- but may then remove it from the DNSKEY RRSet.
-
-6.4. Active Key Compromised
-
- This is the same as the mechanism for Key Roll-Over (Section 6.3)
- above assuming 'A' is the active key.
-
-6.5. Stand-by Key Compromised
-
- Using the same assumptions and naming conventions as Key Roll-Over
- (Section 6.3) above:
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'B'.
- 4. Sign the RRSet with 'A' and 'B'.
- 'B' is now revoked, 'A' remains the active key, and 'C' will be the
- stand-by key once the hold-down expires. 'B' should continue to be
- included in the RRSet for the remove hold-down time.
-
-6.6. Trust Point Deletion
-
- To delete a trust point which is subordinate to another configured
- trust point (e.g. example.com to .com) requires some juggling of the
- data. The specific process is:
- 1. Generate a new DNSKEY and DS record and provide the DS record to
- the parent along with DS records for the old keys
- 2. Once the parent has published the DSs, add the new DNSKEY to the
- RRSet and revoke ALL of the old keys at the same time while
- signing the DNSKEY RRSet with all of the old and new keys.
- 3. After 30 days stop publishing the old, revoked keys and remove
- any corresponding DS records in the parent.
- Revoking the old trust point keys at the same time as adding new keys
- that chain to a superior trust prevents the resolver from adding the
- new keys as trust anchors. Adding DS records for the old keys avoids
- a race condition where either the subordinate zone becomes unsecure
-
-
-
-StJohns Expires June 2, 2007 [Page 10]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- (because the trust point was deleted) or becomes bogus (because it
- didn't chain to the superior zone).
-
-
-7. IANA Considerations
-
- The IANA will need to assign a bit in the DNSKEY flags field (see
- section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
- IANA actions required.
-
-
-8. Security Considerations
-
- In addition to the following sections, see also Theory of Operation
- above and especially Section 2.2 for related discussions.
-
-8.1. Key Ownership vs Acceptance Policy
-
- The reader should note that, while the zone owner is responsible for
- creating and distributing keys, it's wholly the decision of the
- resolver owner as to whether to accept such keys for the
- authentication of the zone information. This implies the decision to
- update trust anchor keys based on trust for a current trust anchor
- key is also the resolver owner's decision.
-
- The resolver owner (and resolver implementers) MAY choose to permit
- or prevent key status updates based on this mechanism for specific
- trust points. If they choose to prevent the automated updates, they
- will need to establish a mechanism for manual or other out-of-band
- updates outside the scope of this document.
-
-8.2. Multiple Key Compromise
-
- This scheme permits recovery as long as at least one valid trust
- anchor key remains uncompromised. E.g. if there are three keys, you
- can recover if two of them are compromised. The zone owner should
- determine their own level of comfort with respect to the number of
- active valid trust anchors in a zone and should be prepared to
- implement recovery procedures once they detect a compromise. A
- manual or other out-of-band update of all resolvers will be required
- if all trust anchor keys at a trust point are compromised.
-
-8.3. Dynamic Updates
-
- Allowing a resolver to update its trust anchor set based on in-band
- key information is potentially less secure than a manual process.
- However, given the nature of the DNS, the number of resolvers that
- would require update if a trust anchor key were compromised, and the
-
-
-
-StJohns Expires June 2, 2007 [Page 11]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- lack of a standard management framework for DNS, this approach is no
- worse than the existing situation.
-
-
-9. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer (DS)", RFC 3755, May 2004.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-Editorial Comments
-
- [msj2] msj: To be assigned.
-
-
-Author's Address
-
- Michael StJohns
- Nominum, Inc.
- 2385 Bay Road
- Redwood City, CA 94063
- USA
-
- Phone: +1-301-528-4729
- Email: Mike.StJohns@nominum.com
- URI: www.nominum.com
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 12]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 13]
-\f
-
+++ /dev/null
-
-
-
-DNSext Working Group F. Dupont
-Internet-Draft ISC
-Updates: 2845,2930,4635 May 8, 2009
-(if approved)
-Intended status: Standards Track
-Expires: November 9, 2009
-
-
- Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records
- draft-ietf-dnsext-tsig-md5-deprecated-03.txt
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79. This document may contain material
- from IETF Documents or IETF Contributions published or made publicly
- available before November 10, 2008. The person(s) controlling the
- copyright in some of this material may not have granted the IETF
- Trust the right to allow modifications of such material outside the
- IETF Standards Process. Without obtaining an adequate license from
- the person(s) controlling the copyright in such materials, this
- document may not be modified outside the IETF Standards Process, and
- derivative works of it may not be created outside the IETF Standards
- Process, except to format it for publication as an RFC or to
- translate it into languages other than English.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on November 9, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
-
-
-Dupont Expires November 9, 2009 [Page 1]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-Abstract
-
- The main purpose of this document is to deprecate the use of HMAC-MD5
- as an algorithm for the TSIG (secret key transaction authentication)
- resource record in the DNS (domain name system), and the use of MD5
- in TKEY (secret key establishment for DNS).
-
-
-1. Introduction
-
- The secret key transaction authentication for DNS (TSIG, [RFC2845])
- was defined with the HMAC-MD5 [RFC2104] cryptographic algorithm.
- When the MD5 [RFC1321] security came to be considered lower than
- expected, [RFC4635] standardized new TSIG algorithms based on SHA
- [RFC3174][RFC3874][RFC4634] digests.
-
- But [RFC4635] did not deprecate the HMAC-MD5 algorithm. This
- document is targeted to complete the process, in detail:
- 1. Mark HMAC-MD5.SIG-ALG.REG.INT as optional in the TSIG algorithm
- name registry managed by the IANA under the IETF Review Policy
- [RFC5226]
- 2. Make HMAC-MD5.SIG-ALG.REG.INT support "not Mandatory" for
- implementations
- 3. Provide a keying material derivation for the secret key
- establishment for DNS (TKEY, [RFC2930]) using a Diffie-Hellman
- exchange with SHA256 [RFC4634] in place of MD5 [RFC1321]
- 4. Finally recommend the use of HMAC-SHA256.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-2. Implementation Requirements
-
- The table of section 3 of [RFC4635] is replaced by:
-
-
-
-
-
-
-
-
-
-Dupont Expires November 9, 2009 [Page 2]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
- +-------------------+--------------------------+
- | Requirement Level | Algorithm Name |
- +-------------------+--------------------------+
- | Optional | HMAC-MD5.SIG-ALG.REG.INT |
- | Optional | gss-tsig |
- | Mandatory | hmac-sha1 |
- | Optional | hmac-sha224 |
- | Mandatory | hmac-sha256 |
- | Optional | hmac-sha384 |
- | Optional | hmac-sha512 |
- +-------------------+--------------------------+
-
- Implementations that support TSIG MUST also implement HMAC-SHA1 and
- HMAC-SHA256 (i.e., algorithms at the "Mandatory" requirement level)
- and MAY implement GSS-TSIG and the other algorithms listed above
- (i.e., algorithms at a "not Mandatory" requirement level).
-
-
-3. TKEY keying material derivation
-
- When the TKEY [RFC2930] uses a Diffie-Hellman exchange, the keying
- material is derived from the shared secret and TKEY resource record
- data using MD5 [RFC1321] at the end of section 4.1 page 9.
-
- This is amended into:
-
- keying material =
- XOR ( DH value, SHA256 ( query data | DH value ) |
- SHA256 ( server data | DH value ) )
-
- using the same conventions.
-
-
-4. IANA Consideration
-
- This document extends the "TSIG Algorithm Names - per [] and
- [RFC2845]" located at
- http://www.iana.org/assignments/tsig-algorithm-names by adding a new
- column to the registry "Compliance Requirement".
-
- The registry should contain the following:
-
-
-
-
-
-
-
-
-
-
-Dupont Expires November 9, 2009 [Page 3]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
- +--------------------------+------------------------+-------------+
- | Algorithm Name | Compliance Requirement | Reference |
- +--------------------------+------------------------+-------------+
- | gss-tsig | Optional | [RFC3645] |
- | HMAC-MD5.SIG-ALG.REG.INT | Optional | [][RFC2845] |
- | hmac-sha1 | Mandatory | [RFC4635] |
- | hmac-sha224 | Optional | [RFC4635] |
- | hmac-sha256 | Mandatory | [RFC4635] |
- | hmac-sha384 | Optional | [RFC4635] |
- | hmac-sha512 | Optional | [RFC4635] |
- +--------------------------+------------------------+-------------+
-
- where [] is this document.
-
-
-5. Availability Considerations
-
- MD5 is no longer universally available and its use may lead to
- increasing operation issues. SHA1 is likely to suffer from the same
- kind of problem. In summary MD5 has reached end-of-life and SHA1
- will likely follow in the near term.
-
- According to [RFC4635], implementations which support TSIG are
- REQUIRED to implement HMAC-SHA256.
-
-
-6. Security Considerations
-
- This document does not assume anything about the cryptographic
- security of different hash algorithms. Its purpose is a better
- availability of some security mechanisms in a predictable time frame.
-
- Requirement levels are adjusted for TSIG and related specifications
- (i.e., TKEY):
- The support of HMAC-MD5 is changed from mandatory to optional.
- The use of MD5 and HMAC-MD5 is NOT RECOMMENDED.
- The use of HMAC-SHA256 is RECOMMENDED.
-
-
-7. Acknowledgments
-
- Olafur Gudmundsson kindly helped in the procedure to deprecate the
- MD5 use in TSIG, i.e., the procedure which led to this memo. Alfred
- Hoenes, Peter Koch, Paul Hoffman and Edward Lewis proposed some
- improvements.
-
-
-8. References
-
-
-
-Dupont Expires November 9, 2009 [Page 4]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, BCP 14, March 1997.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC4635] Eastlake, D., "HMAC SHA TSIG Algorithm Identifiers",
- RFC 4635, August 2006.
-
-8.2. Informative References
-
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104,
- February 1997.
-
- [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
- (SHA1)", RFC 3174, September 2001.
-
- [RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J.,
- and R. Hall, "Generic Security Service Algorithm for
- Secret Key Transaction Authentication for DNS (GSS-TSIG)",
- RFC 3645, October 2003.
-
- [RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224",
- RFC 3874, September 2004.
-
- [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
- (SHA and HMAC-SHA)", RFC 4634, July 2006.
-
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", RFC 5226, BCP 26,
- May 2008.
-
-
-
-
-
-
-
-
-
-
-Dupont Expires November 9, 2009 [Page 5]
-\f
-Internet-Draft Deprecating HMAC-MD5 in TSIG May 2009
-
-
-Author's Address
-
- Francis Dupont
- ISC
-
- Email: Francis.Dupont@fdupont.fr
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dupont Expires November 9, 2009 [Page 6]
-\f
+++ /dev/null
-
-
-
-Network Working Group M. Andrews
-Internet-Draft ISC
-Intended status: BCP June 5, 2008
-Expires: December 7, 2008
-
-
- Locally-served DNS Zones
- draft-ietf-dnsop-default-local-zones-05
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on December 7, 2008.
-
-Abstract
-
- Experience has shown that there are a number of DNS zones all
- iterative resolvers and recursive nameservers should, unless
- configured otherwise, automatically serve. RFC 4193 specifies that
- this should occur for D.F.IP6.ARPA. This document extends the
- practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space
- and other well known zones with similar characteristics.
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 1]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4
- 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4
- 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5
- 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5
- 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6
- 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6
- 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6
- 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7
- 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
- Appendix A. Change History [To Be Removed on Publication] . . . . 10
- A.1. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 10
- A.2. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 10
- A.3. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10
- A.4. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10
- A.5. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11
- A.6. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11
- A.7. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11
- A.8. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11
- Appendix B. Proposed Status [To Be Removed on Publication] . . . 11
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
- Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 2]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-1. Introduction
-
- Experience has shown that there are a number of DNS [RFC 1034] [RFC
- 1035] zones that all iterative resolvers and recursive nameservers
- SHOULD, unless intentionally configured otherwise, automatically
- serve. These zones include, but are not limited to, the IN-ADDR.ARPA
- zones for the address space allocated by [RFC 1918] and the IP6.ARPA
- zones for locally assigned unique local IPv6 addresses, [RFC 4193].
-
- This recommendation is made because data has shown that significant
- leakage of queries for these name spaces is occurring, despite
- instructions to restrict them, and because it has therefore become
- necessary to deploy sacrificial name servers to protect the immediate
- parent name servers for these zones from excessive, unintentional,
- query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every
- expectation that the query load will continue to increase unless
- steps are taken as outlined here.
-
- Additionally, queries from clients behind badly configured firewalls
- that allow outgoing queries for these name spaces but drop the
- responses, put a significant load on the root servers (forward but no
- reverse zones configured). They also cause operational load for the
- root server operators as they have to reply to enquiries about why
- the root servers are "attacking" these clients. Changing the default
- configuration will address all these issues for the zones listed in
- Section 4.
-
- [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled
- locally. This document extends the recommendation to cover the IN-
- ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and
- IP6.ARPA zones for which queries should not appear on the public
- Internet.
-
- It is hoped that by doing this the number of sacrificial servers
- [AS112] will not have to be increased, and may in time be reduced.
-
- This recommendation should also help DNS responsiveness for sites
- which are using [RFC 1918] addresses but do not follow the last
- paragraph in Section 3 of [RFC 1918].
-
-1.1. Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 3]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-2. Effects on sites using RFC 1918 addresses.
-
- For most sites using [RFC 1918] addresses, the changes here will have
- little or no detrimental effect. If the site does not already have
- the reverse tree populated the only effect will be that the name
- error responses will be generated locally rather than remotely.
-
- For sites that do have the reverse tree populated, most will either
- have a local copy of the zones or will be forwarding the queries to
- servers which have local copies of the zone. Therefore this
- recommendation will not be relevant.
-
- The most significant impact will be felt at sites that make use of
- delegations for [RFC 1918] addresses and have populated these zones.
- These sites will need to override the default configuration expressed
- in this document to allow resolution to continue. Typically, such
- sites will be fully disconnected from the Internet and have their own
- root servers for their own non-Internet DNS tree.
-
-
-3. Changes to Iterative Resolver Behaviour.
-
- Unless configured otherwise, an iterative resolver will now return
- authoritatively (aa=1) name errors (RCODE=3) for queries within the
- zones in Section 4, with the obvious exception of queries for the
- zone name itself where SOA, NS and "no data" responses will be
- returned as appropriate to the query type. One common way to do this
- is to serve empty (SOA and NS only) zones.
-
- An implementation of this recommendation MUST provide a mechanism to
- disable this new behaviour, and SHOULD allow this decision on a zone
- by zone basis.
-
- If using empty zones one SHOULD NOT use the same NS and SOA records
- as used on the public Internet servers as that will make it harder to
- detect the origin of the responses and thus any leakage to the public
- Internet servers. This document recommends that the NS record
- defaults to the name of the zone and the SOA MNAME defaults to the
- name of the only NS RR's target. The SOA RNAME should default to
- "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a
- mechanism to set these values. No address records need to be
- provided for the name server.
-
- Below is an example of a generic empty zone in master file format.
- It will produce a negative cache TTL of 3 hours.
-
- @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
- @ 10800 IN NS @
-
-
-
-Andrews Expires December 7, 2008 [Page 4]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- The SOA RR is needed to support negative caching [RFC 2308] of name
- error responses and to point clients to the primary master for DNS
- dynamic updates.
-
- SOA values of particular importance are the MNAME, the SOA RR's TTL
- and the negTTL value. Both TTL values SHOULD match. The rest of the
- SOA timer values MAY be chosen arbitrarily since they are not
- intended to control any zone transfer activity.
-
- The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries
- to discover the zone to be updated. Having no address records for
- the name server is expected to abort UPDATE processing in the client.
-
-
-4. Lists Of Zones Covered
-
- The following subsections are intended to seed the IANA registry as
- requested in the IANA Considerations Section. The zone name is the
- entity to be registered.
-
-4.1. RFC 1918 Zones
-
- The following zones correspond to the IPv4 address space reserved in
- [RFC 1918].
-
- +----------------------+
- | Zone |
- +----------------------+
- | 10.IN-ADDR.ARPA |
- | 16.172.IN-ADDR.ARPA |
- | 17.172.IN-ADDR.ARPA |
- | 18.172.IN-ADDR.ARPA |
- | 19.172.IN-ADDR.ARPA |
- | 20.172.IN-ADDR.ARPA |
- | 21.172.IN-ADDR.ARPA |
- | 22.172.IN-ADDR.ARPA |
- | 23.172.IN-ADDR.ARPA |
- | 24.172.IN-ADDR.ARPA |
- | 25.172.IN-ADDR.ARPA |
- | 26.172.IN-ADDR.ARPA |
- | 27.172.IN-ADDR.ARPA |
- | 28.172.IN-ADDR.ARPA |
- | 29.172.IN-ADDR.ARPA |
- | 30.172.IN-ADDR.ARPA |
- | 31.172.IN-ADDR.ARPA |
- | 168.192.IN-ADDR.ARPA |
- +----------------------+
-
-
-
-
-Andrews Expires December 7, 2008 [Page 5]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-4.2. RFC 3330 Zones
-
- The following zones correspond to those address ranges from [RFC
- 3330] that are not expected to appear as source or destination
- addresses on the public Internet and to not have a unique name to
- associate with.
-
- The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
- attempt to discourage any practice to provide a PTR RR for
- 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse
- mapping should exist, but the exact setup is out of the scope of this
- document. Similar logic applies to the reverse mapping for ::1
- (Section 4.3). The recommendations made here simply assume no other
- coverage for these domains exists.
-
- +------------------------------+------------------------+
- | Zone | Description |
- +------------------------------+------------------------+
- | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
- | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK |
- | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
- | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET |
- | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
- +------------------------------+------------------------+
-
-4.3. Local IPv6 Unicast Addresses
-
- The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for
- the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291],
- Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
-
- +-------------------------------------------+
- | Zone |
- +-------------------------------------------+
- | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
- | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
- | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
- | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
- +-------------------------------------------+
-
- Note: Line breaks and a escapes '\' have been inserted above for
- readability and to adhere to line width constraints. They are not
- parts of the zone names.
-
-4.4. IPv6 Locally Assigned Local Addresses
-
- Section 4.4 of [RFC 4193] already required special treatment of:
-
-
-
-
-Andrews Expires December 7, 2008 [Page 6]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- +--------------+
- | Zone |
- +--------------+
- | D.F.IP6.ARPA |
- +--------------+
-
-4.5. IPv6 Link Local Addresses
-
- IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered
- by four distinct reverse DNS zones:
-
- +----------------+
- | Zone |
- +----------------+
- | 8.E.F.IP6.ARPA |
- | 9.E.F.IP6.ARPA |
- | A.E.F.IP6.ARPA |
- | B.E.F.IP6.ARPA |
- +----------------+
-
-
-5. Zones that are Out-Of-Scope
-
- IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and
- IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered
- here. It is expected that IPv6 site-local addresses will be self
- correcting as IPv6 implementations remove support for site-local
- addresses. However, sacrificial servers for C.E.F.IP6.ARPA through
- F.E.F.IP6.ARPA may still need to be deployed in the short term if the
- traffic becomes excessive.
-
- For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193],
- there has been no decision made about whether the Regional Internet
- Registries (RIRs) will provide delegations in this space or not. If
- they don't, then C.F.IP6.ARPA will need to be added to the list in
- Section 4.4. If they do, then registries will need to take steps to
- ensure that name servers are provided for these addresses.
-
- This document also ignores IP6.INT. IP6.INT has been wound up with
- only legacy resolvers now generating reverse queries under IP6.INT
- [RFC 4159].
-
- This document has also deliberately ignored names immediately under
- the root domain. While there is a subset of queries to the root name
- servers which could be addressed using the techniques described here
- (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
- amount of traffic that requires a different strategy (e.g. lookups
- for unqualified hostnames, IPv6 addresses).
-
-
-
-Andrews Expires December 7, 2008 [Page 7]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-6. IANA Considerations
-
- This document requests that IANA establish a registry of zones which
- require this default behaviour. The initial contents of which are in
- Section 4. Implementors are encouraged to check this registry and
- adjust their implementations to reflect changes therein.
-
- This registry can be amended through "IETF Consensus" as per [RFC
- 2434].
-
- IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
- deployed in the reverse tree, delegations for these zones are made in
- the manner described in Section 7.
-
-
-7. Security Considerations
-
- During the initial deployment phase, particularly where [RFC 1918]
- addresses are in use, there may be some clients that unexpectedly
- receive a name error rather than a PTR record. This may cause some
- service disruption until their recursive name server(s) have been re-
- configured.
-
- As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
- namespaces, the zones listed above will need to be delegated as
- insecure delegations, or be within insecure zones. This will allow
- DNSSEC validation to succeed for queries in these spaces despite not
- being answered from the delegated servers.
-
- It is recommended that sites actively using these namespaces secure
- them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
- anchors. This will protect the clients from accidental import of
- unsigned responses from the Internet.
-
-
-8. Acknowledgements
-
- This work was supported by the US National Science Foundation
- (research grant SCI-0427144) and DNS-OARC.
-
-
-9. References
-
-9.1. Normative References
-
- [RFC 1034]
- Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- STD 13, RFC 1034, November 1987.
-
-
-
-Andrews Expires December 7, 2008 [Page 8]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- [RFC 1035]
- Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION", STD 13, RFC 1035, November 1987.
-
- [RFC 1918]
- Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
- and E. Lear, "Address Allocation for Private Internets",
- BCP 5, RFC 1918, February 1996.
-
- [RFC 2119]
- Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2136]
- Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC 2308]
- Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2398, March 1998.
-
- [RFC 2434]
- Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC 2606]
- Eastlake, D. and A. Panitz, "Reserved Top Level DNS
- Names", BCP 32, RFC 2606, June 1999.
-
- [RFC 3596]
- Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
- "DNS Extensions to Support IPv6", RFC 3596, October 2003.
-
- [RFC 4035]
- Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC 4159]
- Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
- August 2005.
-
- [RFC 4193]
- Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
- Addresses", RFC 4193, October 2005.
-
-
-
-
-Andrews Expires December 7, 2008 [Page 9]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- [RFC 4291]
- Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
-9.2. Informative References
-
- [AS112] "AS112 Project", <http://www.as112.net/>.
-
- [I-D.draft-ietf-dnsop-as112-ops]
- Abley, J. and W. Maton, "AS112 Nameserver Operations",
- draft-ietf-dnsop-as112-ops-00 (work in progress),
- February 2007.
-
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
- Abley, J. and W. Maton, "I'm Being Attacked by
- PRISONER.IANA.ORG!",
- draft-ietf-dnsop-as112-under-attack-help-help-00 (work in
- progress), February 2007.
-
- [RFC 3330]
- "Special-Use IPv4 Addresses", RFC 3330, September 2002.
-
-
-Appendix A. Change History [To Be Removed on Publication]
-
-A.1. draft-ietf-dnsop-default-local-zones-05.txt
-
- none, expiry prevention
-
-A.2. draft-ietf-dnsop-default-local-zones-04.txt
-
- Centrally Assigned Local addresses -> Non-Locally Assigned Local
- address
-
-A.3. draft-ietf-dnsop-default-local-zones-03.txt
-
- expanded section 4 descriptions
-
- Added references [RFC 2136], [RFC 3596],
- [I-D.draft-ietf-dnsop-as112-ops] and
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
-
- Revised language.
-
-A.4. draft-ietf-dnsop-default-local-zones-02.txt
-
- RNAME now "nobody.invalid."
-
-
-
-
-Andrews Expires December 7, 2008 [Page 10]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- Revised language.
-
-A.5. draft-ietf-dnsop-default-local-zones-01.txt
-
- Revised impact description.
-
- Updated to reflect change in IP6.INT status.
-
-A.6. draft-ietf-dnsop-default-local-zones-00.txt
-
- Adopted by DNSOP.
-
- "Author's Note" re-titled "Zones that are Out-Of-Scope"
-
- Add note that these zone are expected to seed the IANA registry.
-
- Title changed.
-
-A.7. draft-andrews-full-service-resolvers-03.txt
-
- Added "Proposed Status".
-
-A.8. draft-andrews-full-service-resolvers-02.txt
-
- Added 0.IN-ADDR.ARPA.
-
-
-Appendix B. Proposed Status [To Be Removed on Publication]
-
- This Internet-Draft is being submitted for eventual publication as an
- RFC with a proposed status of Best Current Practice.
-
-
-Author's Address
-
- Mark P. Andrews
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- US
-
- Email: Mark_Andrews@isc.org
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 11]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 12]
-\f
+++ /dev/null
-
-
-
-DNSOP W. Hardaker
-Internet-Draft Sparta, Inc.
-Intended status: Informational February 12, 2009
-Expires: August 16, 2009
-
-
- Requirements for Management of Name Servers for the DNS
- draft-ietf-dnsop-name-server-management-reqs-02.txt
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 16, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (http://trustee.ietf.org/license-info) in effect on the date of
- publication of this document. Please review these documents
- carefully, as they describe your rights and restrictions with respect
- to this document.
-
-Abstract
-
- Management of name servers for the Domain Name Service (DNS) has
- traditionally been done using vendor-specific monitoring,
-
-
-
-Hardaker Expires August 16, 2009 [Page 1]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- configuration and control methods. Although some service monitoring
- platforms can test the functionality of the DNS itself there is not a
- interoperable way to manage (monitor, control and configure) the
- internal aspects of a name server itself.
-
- This document discusses the requirements of a management system for
- DNS name servers. A management solution that is designed to manage
- the DNS can use this document as a shopping list of needed features.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
- 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 5
- 1.1.2. Document Layout and Requirements . . . . . . . . . . . 5
- 2. Management Architecture Requirements . . . . . . . . . . . . . 5
- 2.1. Expected Deployment Scenarios . . . . . . . . . . . . . . 5
- 2.1.1. Zone Size Constraints . . . . . . . . . . . . . . . . 5
- 2.1.2. Name Server Discovery . . . . . . . . . . . . . . . . 6
- 2.1.3. Configuration Data Volatility . . . . . . . . . . . . 6
- 2.1.4. Protocol Selection . . . . . . . . . . . . . . . . . . 6
- 2.1.5. Common Data Model . . . . . . . . . . . . . . . . . . 6
- 2.1.6. Operational Impact . . . . . . . . . . . . . . . . . . 7
- 2.2. Name Server Types . . . . . . . . . . . . . . . . . . . . 7
- 3. Management Operation Types . . . . . . . . . . . . . . . . . . 7
- 3.1. Control Requirements . . . . . . . . . . . . . . . . . . . 8
- 3.1.1. Needed Control Operations . . . . . . . . . . . . . . 8
- 3.1.2. Asynchronous Status Notifications . . . . . . . . . . 8
- 3.2. Configuration Requirements . . . . . . . . . . . . . . . . 9
- 3.2.1. Served Zone Modification . . . . . . . . . . . . . . . 9
- 3.2.2. Trust Anchor Management . . . . . . . . . . . . . . . 9
- 3.2.3. Security Expectations . . . . . . . . . . . . . . . . 9
- 3.2.4. TSIG Key Management . . . . . . . . . . . . . . . . . 9
- 3.2.5. DNS Protocol Authorization Management . . . . . . . . 9
- 3.3. Monitoring Requirements . . . . . . . . . . . . . . . . . 10
- 3.4. Alarm and Event Requirements . . . . . . . . . . . . . . . 10
- 4. Security Requirements . . . . . . . . . . . . . . . . . . . . 11
- 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 11
- 4.2. Integrity Protection . . . . . . . . . . . . . . . . . . . 11
- 4.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 11
- 4.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 11
- 4.5. Solution Impacts on Security . . . . . . . . . . . . . . . 12
- 5. Other Requirements . . . . . . . . . . . . . . . . . . . . . . 12
- 5.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12
- 5.1.1. Vendor Extensions . . . . . . . . . . . . . . . . . . 13
- 5.1.2. Extension Identification . . . . . . . . . . . . . . . 13
- 5.1.3. Name-Space Collision Protection . . . . . . . . . . . 13
-
-
-
-Hardaker Expires August 16, 2009 [Page 2]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
- 8. Document History . . . . . . . . . . . . . . . . . . . . . . . 13
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
- Appendix A. Deployment Scenarios . . . . . . . . . . . . . . . . 15
- A.1. Non-Standard Zones . . . . . . . . . . . . . . . . . . . . 16
- A.2. Redundancy Sharing . . . . . . . . . . . . . . . . . . . . 16
- A.3. DNSSEC Management . . . . . . . . . . . . . . . . . . . . 16
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 3]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-1. Introduction
-
- Management of name servers for the Domain Name Service (DNS)
- [RFC1034] [RFC1035] has traditionally been done using vendor-specific
- monitoring, configuration and control methods. Although some service
- monitoring platforms can test the functionality of the DNS itself
- there is not a interoperable way to manage (monitor, control and
- configure) the internal aspects of a name server itself.
-
- Previous standardization work within the IETF resulted in the
- creation of two SNMP MIB modules [RFC1611] [RFC1612] but they failed
- to achieve significant implementation and deployment. The perceived
- reasons behind the failure for the two MIB modules are further
- documented in [RFC3197].
-
- This document discusses the requirements of a management system for
- DNS name servers. A management solution that is designed to manage
- the DNS can use this document as a shopping list of needed features.
-
- Specifically out of scope for this document are requirements
- associated with management of stub resolvers. It is not the intent
- of this document to document stub resolver requirements, although
- some of the requirements listed are applicable to stub resolvers as
- well.
-
- Also out of scope for this document is management of the host or
- other components of the host upon which the name server software is
- running. This document only discusses requirements for managing the
- name server component of a system.
-
- The task of creating a management system for managing DNS servers is
- not expected to be a small one. It is likely that components of the
- solution will need to be designed in parts over time and these
- requirements take this into consideration. In particular,
- Section 5.1 discusses the need for future extensibility of the base
- management solution. This document is intended to be a road-map
- towards a desired outcome and is not intended to define an "all-or-
- nothing" system. Successful interoperable management of name servers
- even in part is expected to be beneficial to network operators
- compared to the entirely custom solutions that are used at the time
- of this writing.
-
-1.1. Requirements notation
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 4]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-1.1.1. Terminology
-
- This document is consistent with the terminology defined in Section 2
- of [RFC4033]. Additional terminology needed for this document is
- described below:
-
- Name Server: When we are discussing servers that don't fall into a
- more specific type of server category defined in other documents,
- this document will refer to them generically as "name servers".
- In particular "name servers" can be considered to be any valid
- combination of authoritative, recursive, validating, or security-
- aware. The more specific name server labels will be used when
- this document refers only to a specific type of server. However,
- the term "name server", in this document, will not include stub
- resolvers.
-
-1.1.2. Document Layout and Requirements
-
- The document is written so that each numbered section will contain
- only a single requirement if it contains one at all. Each
- requirement will contain needed wording from the terminology
- described in Section 1.1. Subsections, however, might exist with
- additional related requirements. The document is laid out in this
- way so that a specific requirement can be uniquely referred to using
- the section number itself and the document version from which it
- came.
-
-
-2. Management Architecture Requirements
-
- This section discusses requirements that reflect the needs of the
- expected deployment environments.
-
-2.1. Expected Deployment Scenarios
-
- DNS zones vary greatly in the type of content published within them.
- Name Servers, too, are deployed with a wide variety of configurations
- to support the diversity of the deployed content. It is important
- that a management solution trying to meet the criteria specified in
- this document consider supporting the largest number of potential
- deployment cases as possible. Further deployment scenarios that are
- not used as direct examples of specific requirements are listed in
- Appendix A.
-
-2.1.1. Zone Size Constraints
-
- The management solution MUST support both name servers that are
- serving a small number of potentially very large zones (e.g. Top
-
-
-
-Hardaker Expires August 16, 2009 [Page 5]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- Level Domains (TLDs)) as well as name servers that are serving a very
- large number of small zones. These scenarios are both commonly seen
- deployments.
-
-2.1.2. Name Server Discovery
-
- Large enterprise network deployments may contain multiple name
- servers operating within the boundaries of the enterprise network.
- These name servers may each be serving multiple zones both in and out
- of the parent enterprise's zone. Finding and managing large
- quantities of name servers would be a useful feature of the resulting
- management solution. The management solution MAY support the ability
- to discover previously unknown instances of name servers operating
- within a deployed network.
-
-2.1.3. Configuration Data Volatility
-
- Configuration data is defined as data that relates only to the
- configuration of a server and the zones it serves. It specifically
- does not include data from the zone contents that is served through
- DNS itself. The solution MUST support servers that remain fairly
- statically configured over time as well as servers that have numerous
- zones being added and removed within an hour. Both of these
- scenarios are also commonly seen deployments.
-
-2.1.4. Protocol Selection
-
- There are many requirements in this document for many different types
- of management operations (see Section 3 for further details). It is
- possible that no one protocol will ideally fill all the needs of the
- requirements listed in this document and thus multiple protocols
- might be needed to produce a completely functional management system.
- Multiple protocols might be used to create the complete management
- solution, but the number of protocols used SHOULD be reduced to a
- reasonable minimum number.
-
-2.1.5. Common Data Model
-
- Defining a standardized protocol (or set of protocols) to use for
- managing name servers would be a step forward in achieving an
- interoperable management solution. However, just defining a protocol
- to use by itself would not achieve the complete end goal of a
- complete interoperable management solution. Devices also need to
- represent their internal management interface using a common
- management data model. The solution MUST create a common data model
- that management stations can make use of when sending or collecting
- data from a managed device so it can successfully manage equipment
- from vendors as if they were generic DNS servers. This common data
-
-
-
-Hardaker Expires August 16, 2009 [Page 6]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- model is needed for of the operations discussion in Section 3. Note
- that this does not preclude the fact that name server vendors might
- provide additional management infrastructure beyond a base management
- specification, as discussed further in Section 5.1.
-
-2.1.6. Operational Impact
-
- It is impossible to add new features to an existing server (such as
- the inclusion of a management infrastructure) and not impact the
- existing service and/or server in some fashion. At a minimum, for
- example, more memory, disk and/or CPU resources will be required to
- implement a new management system. However, the impact to the
- existing DNS service MUST be minimized since the DNS service itself
- is still the primary service to be offered by the modified name
- server.
-
-2.2. Name Server Types
-
- There are multiple ways in which name servers can be deployed. Name
- servers can take on any of the following roles:
-
- o Master Servers
-
- o Slave Servers
-
- o Recursive Servers
-
- The management solution SHOULD support all of these types of name
- servers as they are all equally important. Note that "Recursive
- Servers" can be further broken down by the security sub-roles they
- might implement, as defined in section 2 of [RFC4033]. These sub-
- roles are also important to support within any management solution.
-
- As stated earlier, the management of stub resolvers is considered out
- of scope for this documents.
-
-
-3. Management Operation Types
-
- Management operations can traditionally be broken into four
- categories:
-
- o Control
-
- o Configuration
-
- o Health and Monitoring
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 7]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- o Alarms and Events
-
- This section discusses requirements for each of these four management
- types in detail.
-
-3.1. Control Requirements
-
- The management solution MUST be capable of performing basic service
- control operations.
-
-3.1.1. Needed Control Operations
-
- These operations SHOULD include, at a minimum, the following
- operations:
-
- o Starting the name server
-
- o Reloading the service configuration
-
- o Reloading zone data
-
- o Restarting the name server
-
- o Stopping the name server
-
- Note that no restriction is placed on how the management system
- implements these operations. In particular, at least "starting the
- name server" will require a minimal management system component to
- exist independently of the name server itself.
-
-3.1.2. Asynchronous Status Notifications
-
- Some control operations might take a long time to complete. As an
- example, some name servers take a long time to perform reloads of
- large zones. Because of these timing issues, the management solution
- SHOULD take this into consideration and offer a mechanism to ease the
- burden associated with awaiting the status of a long-running command.
- This could, for example, result in the use of asynchronous
- notifications for returning the status of a long-running task or it
- might require the management station to poll for the status of a
- given task using monitoring commands. These and other potential
- solutions need to be evaluated carefully to select one that balances
- the result delivery needs with the perceived implementation costs.
-
- Also, see the related discussion in Section 3.4 on notification
- messages for supporting delivery of alarm and event messages.
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 8]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-3.2. Configuration Requirements
-
- Many features of name servers need to be configured before the server
- can be considered functional. The management solution MUST be able
- to provide name servers with configuration data. The most important
- data to be configured, for example, is the served zone data itself.
-
-3.2.1. Served Zone Modification
-
- The ability to add, modify and delete zones being served by name
- servers is needed. Although there are already solutions for zone
- content modification (such as Dynamic DNS (DDNS) [RFC2136] [RFC3007],
- AXFR [RFC1035], and incremental zone transfer (IXFR) [RFC1995]) that
- might be used as part of the final management solution, the
- management system SHOULD still be able to natively create a new zone
- (with enough minimal data to allow the other mechanisms to function
- as well) as well as delete a zone. This might be, for example, a
- management operation that at least allows for the creation of the
- initial SOA record for a new zone as that's the minimum amount of
- zone data needed for the other operations to function.
-
-3.2.2. Trust Anchor Management
-
- The solution SHOULD support the ability to add, modify and delete
- trust anchors that are used by DNS Security (DNSSEC) [RFC4033]
- [RFC4034] [RFC4035] [RFC4509] [RFC5011] [RFC5155]. These trust
- anchors might be configured using the data from the DNSKEY Resource
- Records (RRs) themselves or by using Delegation Signer (DS)
- fingerprints.
-
-3.2.3. Security Expectations
-
- DNSSEC Validating resolvers need to make policy decisions about the
- requests being processed. For example, they need to be configured
- with a list of zones expected to be secured by DNSSEC. The
- management solution SHOULD be able to add, modify and delete
- attributes of DNSSEC security policies.
-
-3.2.4. TSIG Key Management
-
- TSIG [RFC2845] allows transaction level authentication of DNS
- traffic. The management solution SHOULD be able to add, modify and
- delete TSIG keys known to the name server.
-
-3.2.5. DNS Protocol Authorization Management
-
- The management solution SHOULD have the ability to add, modify and
- delete authorization settings for the DNS protocols itself. Do not
-
-
-
-Hardaker Expires August 16, 2009 [Page 9]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- confuse this with the ability to manage the authorization associated
- with the management protocol itself, which is discussed later in
- Section 4.4. There are a number of authorization settings that are
- used by a name server. Example authorization settings that the
- solution might need to cover are:
-
- o Access to operations on zone data (e.g. DDNS)
-
- o Access to certain zone data from certain sources (e.g. from
- particular network subnets)
-
- o Access to specific DNS protocol services (e.g. recursive service)
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed authorization
- protections.
-
-3.3. Monitoring Requirements
-
- Monitoring is the process of collecting aspects of the internal state
- of a name server at a given moment in time. The solution MUST be
- able to monitor the health of a name server to determine its
- operational status, load and other internal attributes. Example
- management tasks that the solution might need to cover are:
-
- o Number of requests sent, responses sent, average response latency
- and other performance counters
-
- o Server status (e.g. "serving data", "starting up", "shutting
- down", ...)
-
- o Access control violations
-
- o List of zones being served
-
- o Detailed statistics about clients interacting with the name server
- (e.g. top 10 clients requesting data).
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed monitoring operations.
- In particular, some monitoring statistics are expected to be
- computationally or resource expensive and are considered to be "nice
- to haves" as opposed to "necessary to have".
-
-3.4. Alarm and Event Requirements
-
- Events occurring at the name server that trigger alarm notifications
- can quickly inform a management station about critical issues. A
-
-
-
-Hardaker Expires August 16, 2009 [Page 10]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- management solution SHOULD include support for delivery of alarm
- conditions.
-
- Example alarm conditions might include:
-
- o The server's status is changing. (e.g it is starting up, reloading
- configuration, restarting or shutting down)
-
- o A needed resource (e.g. memory or disk space) is exhausted or
- nearing exhaustion
-
- o An authorization violation was detected
-
- o The server has not received any data traffic (e.g. DNS requests
- or NOTIFYs) recently (AKA the "lonely warning"). This condition
- might indicate a problem with its deployment.
-
-
-4. Security Requirements
-
- The management solution will need to be appropriately secured against
- attacks on the management infrastructure.
-
-4.1. Authentication
-
- The solution MUST support mutual authentication. The management
- client needs to be assured that the management operations are being
- transferred to and from the correct name server. The managed name
- server needs to authenticate the system that is accessing the
- management infrastructure within itself.
-
-4.2. Integrity Protection
-
- Management operations MUST be protected from modification while in
- transit from the management client to the server.
-
-4.3. Confidentiality
-
- The management solution MUST support message confidentiality. The
- potential transfer of sensitive configuration is expected (such as
- TSIG keys or security policies). The solution does not, however,
- necessarily need to provide confidentiality to data that would
- normally be carried without confidentiality by the DNS system itself.
-
-4.4. Authorization
-
- The solution SHOULD be capable of providing a fine-grained
- authorization model for any management protocols it introduces to the
-
-
-
-Hardaker Expires August 16, 2009 [Page 11]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- completed system. This authorization differs from the authorization
- previously discussed in Section 3.2.5 in that this requirement is
- concerned solely with authorization of the management system itself.
-
- There are a number of authorization settings that might be used by a
- managed system to determine whether the managing entity has
- authorization to perform the given management task. Example
- authorization settings that the solution might need to cover are:
-
- o Access to the configuration that specifies which zones are to be
- served
-
- o Access to the management system infrastructure
-
- o Access to other control operations
-
- o Access to other configuration operations
-
- o Access to monitoring operations
-
- Note: the above list is expected to be used as a collection of
- examples and is not a complete list of needed authorization
- protections.
-
-4.5. Solution Impacts on Security
-
- The solution MUST minimize the security risks introduced to the
- complete name server system. It is impossible to add new
- infrastructure to a server and not impact the security in some
- fashion as the introduction of a management protocol alone will
- provide a new avenue for potential attack. Although the added
- management benefits will be worth the increased risks, the solution
- still needs to minimize this impact as much as possible.
-
-
-5. Other Requirements
-
-5.1. Extensibility
-
- The management solution is expected to change and expand over time as
- lessons are learned and new DNS features are deployed. Thus, the
- solution MUST be flexible and be able to accommodate new future
- management operations. The solution might, for example, make use of
- protocol versioning or capability description exchanges to ensure
- that management stations and name servers that weren't written to the
- same specification version can still interoperate to the best of
- their combined ability.
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 12]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
-5.1.1. Vendor Extensions
-
- It MUST be possible for vendors to extend the standardized management
- model with vendor-specific extensions to support additional features
- offered by their products.
-
-5.1.2. Extension Identification
-
- It MUST be possible for a management station to understand which
- parts of returned data are specific to a given vendor or other
- standardized extension. The data returned needs to be appropriately
- marked through the use of name spaces or similar mechanisms to ensure
- that the base management model data can be logically separated from
- extension data without needing to understand the extension data
- itself.
-
-5.1.3. Name-Space Collision Protection
-
- It MUST be possible to protect against multiple extensions
- conflicting with each other. The use of name-space protection
- mechanisms for communicated management variables is common practice
- to protect against problems. Name-space identification techniques
- also frequently solve the "Extension Identification" requirement
- discussed in Section 5.1.2 as well.
-
-
-6. Security Considerations
-
- Any management protocol that meets the criteria discussed in this
- document needs to support the criteria discussed in Section 4 in
- order to protect the management infrastructure itself. The DNS is a
- core Internet service and management traffic that protects it could
- be the target of attacks designed to subvert that service. Because
- the management infrastructure will be adding additional interfaces to
- that service, it is critical that the management infrastructure
- support adequate protections against network attacks.
-
-
-7. IANA Considerations
-
- No action is required from IANA for this document.
-
-
-8. Document History
-
- A requirement gathering discussion was held at the December 2007 IETF
- meeting in Vancouver, BC, Canada and a follow up meeting was held at
- the March 2008 IETF meeting in Philadelphia. This document is a
-
-
-
-Hardaker Expires August 16, 2009 [Page 13]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- compilation of the results of those discussions as well as
- discussions on the DCOMA mailing list.
-
-
-9. Acknowledgments
-
- This draft is the result of discussions within the DCOMA design team
- chaired by Jaap Akkerhuis. This team consisted of a large number of
- people all of whom provided valuable insight and input into the
- discussions surrounding name server management. The text of this
- document was written from notes taken during meetings as well as from
- contributions sent to the DCOMA mailing list. This work documents
- the consensus of the DCOMA design team.
-
- In particular, the following team members contributed significantly
- to the text in the document:
-
- Stephane Bortzmeyer
-
- Stephen Morris
-
- Phil Regnauld
-
- Further editing contributions and wording suggestions were made by:
- Alfred Hoenes.
-
-
-10. References
-
-10.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
- August 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
-
-
-
-Hardaker Expires August 16, 2009 [Page 14]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
- Trust Anchors", RFC 5011, September 2007.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-10.2. Informative References
-
- [RFC1611] Austein, R. and J. Saperia, "DNS Server MIB Extensions",
- RFC 1611, May 1994.
-
- [RFC1612] Austein, R. and J. Saperia, "DNS Resolver MIB Extensions",
- RFC 1612, May 1994.
-
- [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
- and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
- July 1997.
-
- [RFC3197] Austein, R., "Applicability Statement for DNS MIB
- Extensions", RFC 3197, November 2001.
-
-
-Appendix A. Deployment Scenarios
-
- This appendix documents some additional deployment scenarios that
- have been traditionally difficult to manage. They are provided as
-
-
-
-Hardaker Expires August 16, 2009 [Page 15]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- guidance to protocol developers as data points of real-world name
- server management problems.
-
-A.1. Non-Standard Zones
-
- If an organization uses non-standard zones (for example a purely-
- local TLD), synchronizing all the name servers for these zones is
- usually a time-consuming task. It is made worse when two
- organizations with conflicting zones merge. This situation is not a
- recommended deployment scenario (and is even heavily discouraged) but
- it is, unfortunately, seen in the wild.
-
- It is typically implemented using "forwarding" zones. But there is
- no way to ensure automatically that all the resolvers have the same
- set of zones to forward at any given time. New zones might be added
- to a local forwarding recursive server, for example, without
- modifying the rest of the deployed forwarding servers. It is hoped
- that a management solution which could handle the configuration of
- zone forwarding would finally allow management of servers deployed in
- this fashion.
-
-A.2. Redundancy Sharing
-
- For reliability reasons it is recommended that zone operators follow
- the guidelines documented in [RFC2182] which recommends that multiple
- name servers be configured for each zone and that the name servers
- are separated both physically and via connectivity routes. A common
- solution is to establish DNS-serving partnerships: "I'll host your
- zones and you'll host mine". Both entities benefit from increased
- DNS reliability via the wider service distribution. This frequently
- occurs between cooperating but otherwise unrelated entities (such as
- between two distinct companies) as well as between affiliated
- organizations (such as between branch offices within a single
- company).
-
- The configuration of these relationships are currently required to be
- manually configured and maintained. Changes to the list of zones
- that are cross-hosted are manually negotiated between the cooperating
- network administrators and configured by hand. A management protocol
- with the ability to provide selective authorization, as discussed in
- Section 4.4, would solve many of the management difficulties between
- cooperating organizations.
-
-A.3. DNSSEC Management
-
- There are many different DNSSEC deployment strategies that may be
- used for mission-critical zones. The following list describes some
- example deployment scenarios that might warrant different management
-
-
-
-Hardaker Expires August 16, 2009 [Page 16]
-\f
-Internet-Draft Name Server Management Requirements February 2009
-
-
- strategies.
-
- All contents and DNSSEC keying information controlled and operated
- by a single organization
-
- Zone contents controlled and operated by one organization, all
- DNSSEC keying information controlled and operated by a second
- organization.
-
- Zone contents controlled and operated by one organization, zone
- signing keys (ZSKs) controlled and operated by a second
- organization, and key signing keys (KSKs) controlled and operated
- by a third organization.
-
- Although this list is not exhaustive in the potential ways that zone
- data can be divided up, it should be sufficient to illustrate the
- potential ways in which zone data can be controlled by multiple
- entities.
-
- The end result of all of these strategies, however, will be the same:
- a live zone containing DNSSEC related resource records. Many of the
- above strategies are merely different ways of preparing a zone for
- serving. A management solution that includes support for managing
- DNSSEC zone data may wish to take into account these potential
- management scenarios.
-
-
-Author's Address
-
- Wes Hardaker
- Sparta, Inc.
- P.O. Box 382
- Davis, CA 95617
- US
-
- Phone: +1 530 792 1913
- Email: ietf@hardakers.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 16, 2009 [Page 17]
-\f
+++ /dev/null
-
-
-
-
-
-
- DNSOP Working Group Paul Vixie, ISC
- INTERNET-DRAFT Akira Kato, WIDE
- <draft-ietf-dnsop-respsize-06.txt> August 2006
-
- DNS Referral Response Size Issues
-
- Status of this Memo
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2006). All Rights Reserved.
-
-
-
-
- Abstract
-
- With a mandated default minimum maximum message size of 512 octets,
- the DNS protocol presents some special problems for zones wishing to
- expose a moderate or high number of authority servers (NS RRs). This
- document explains the operational issues caused by, or related to
- this response size limit, and suggests ways to optimize the use of
- this limited space. Guidance is offered to DNS server implementors
- and to DNS zone operators.
-
-
-
-
- Expires January 2007 [Page 1]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- 1 - Introduction and Overview
-
- 1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
- octets. Even though this limitation was due to the required minimum IP
- reassembly limit for IPv4, it became a hard DNS protocol limit and is
- not implicitly relaxed by changes in transport, for example to IPv6.
-
- 1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
- larger responses by mutual agreement of the requester and responder.
- The 512 octet message size limit will remain in practical effect until
- there is widespread deployment of EDNS0 in DNS resolvers on the
- Internet.
-
- 1.3. Since DNS responses include a copy of the request, the space
- available for response data is somewhat less than the full 512 octets.
- Negative responses are quite small, but for positive and delegation
- responses, every octet must be carefully and sparingly allocated. This
- document specifically addresses delegation response sizes.
-
- 2 - Delegation Details
-
- 2.1. RELEVANT PROTOCOL ELEMENTS
-
- 2.1.1. A delegation response will include the following elements:
-
- Header Section: fixed length (12 octets)
- Question Section: original query (name, class, type)
- Answer Section: empty, or a CNAME/DNAME chain
- Authority Section: NS RRset (nameserver names)
- Additional Section: A and AAAA RRsets (nameserver addresses)
-
- 2.1.2. If the total response size exceeds 512 octets, and if the data
- that does not fit was "required", then the TC bit will be set
- (indicating truncation). This will usually cause the requester to retry
- using TCP, depending on what information was desired and what
- information was omitted. For example, truncation in the authority
- section is of no interest to a stub resolver who only plans to consume
- the answer section. If a retry using TCP is needed, the total cost of
- the transaction is much higher. See [RFC1123 6.1.3.2] for details on
- the requirement that UDP be attempted before falling back to TCP.
-
- 2.1.3. RRsets are never sent partially unless TC bit set to indicate
- truncation. When TC bit is set, the final apparent RRset in the final
- non-empty section must be considered "possibly damaged" (see [RFC1035
- 6.2], [RFC2181 9]).
-
-
-
- Expires January 2007 [Page 2]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- 2.1.4. With or without truncation, the glue present in the additional
- data section should be considered "possibly incomplete", and requesters
- should be prepared to re-query for any damaged or missing RRsets. Note
- that truncation of the additional data section might not be signalled
- via the TC bit since additional data is often optional (see discussion
- in [RFC4472 B]).
-
- 2.1.5. DNS label compression allows a domain name to be instantiated
- only once per DNS message, and then referenced with a two-octet
- "pointer" from other locations in that same DNS message (see [RFC1035
- 4.1.4]). If all nameserver names in a message share a common parent
- (for example, all ending in ".ROOT-SERVERS.NET"), then more space will
- be available for incompressable data (such as nameserver addresses).
-
- 2.1.6. The query name can be as long as 255 octets of network data. In
- this worst case scenario, the question section will be 259 octets in
- size, which would leave only 240 octets for the authority and additional
- sections (after deducting 12 octets for the fixed length header.)
-
- 2.2. ADVICE TO ZONE OWNERS
-
- 2.2.1. Average and maximum question section sizes can be predicted by
- the zone owner, since they will know what names actually exist, and can
- measure which ones are queried for most often. Note that if the zone
- contains any wildcards, it is possible for maximum length queries to
- require positive responses, but that it is reasonable to expect
- truncation and TCP retry in that case. For cost and performance
- reasons, the majority of requests should be satisfied without truncation
- or TCP retry.
-
- 2.2.2. Some queries to non-existing names can be large, but this is not
- a problem because negative responses need not contain any answer,
- authority or additional records. See [RFC2308 2.1] for more information
- about the format of negative responses.
-
- 2.2.3. The minimum useful number of name servers is two, for redundancy
- (see [RFC1034 4.1]). A zone's name servers should be reachable by all
- IP transport protocols (e.g., IPv4 and IPv6) in common use.
-
- 2.2.4. The best case is no truncation at all. This is because many
- requesters will retry using TCP immediately, or will automatically re-
- query for RRsets that are possibly truncated, without considering
- whether the omitted data was actually necessary.
-
-
-
-
-
- Expires January 2007 [Page 3]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- 2.3. ADVICE TO SERVER IMPLEMENTORS
-
- 2.3.1. In case of multi-homed name servers, it is advantageous to
- include an address record from each of several name servers before
- including several address records for any one name server. If address
- records for more than one transport (for example, A and AAAA) are
- available, then it is advantageous to include records of both types
- early on, before the message is full.
-
- 2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
- class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
- Each A RR will require 16 octets, and each AAAA RR will require 28
- octets.
-
- 2.3.3. While DNS distinguishes between necessary and optional resource
- records, this distinction is according to protocol elements necessary to
- signify facts, and takes no official notice of protocol content
- necessary to ensure correct operation. For example, a nameserver name
- that is in or below the zone cut being described by a delegation is
- "necessary content," since there is no way to reach that zone unless the
- parent zone's delegation includes "glue records" describing that name
- server's addresses.
-
- 2.3.4. It is also necessary to distinguish between "explicit truncation"
- where a message could not contain enough records to convey its intended
- meaning, and so the TC bit has been set, and "silent truncation", where
- the message was not large enough to contain some records which were "not
- required", and so the TC bit was not set.
-
- 2.3.5. A delegation response should prioritize glue records as follows.
-
- first
- All glue RRsets for one name server whose name is in or below the
- zone being delegated, or which has multiple address RRsets (currently
- A and AAAA), or preferably both;
-
- second
- Alternate between adding all glue RRsets for any name servers whose
- names are in or below the zone being delegated, and all glue RRsets
- for any name servers who have multiple address RRsets (currently A
- and AAAA);
-
- thence
- All other glue RRsets, in any order.
-
-
-
-
- Expires January 2007 [Page 4]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- Whenever there are multiple candidates for a position in this priority
- scheme, one should be chosen on a round-robin or fully random basis.
-
- The goal of this priority scheme is to offer "necessary" glue first,
- avoiding silent truncation for this glue if possible.
-
- 2.3.6. If any "necessary content" is silently truncated, then it is
- advisable that the TC bit be set in order to force a TCP retry, rather
- than have the zone be unreachable. Note that a parent server's proper
- response to a query for in-child glue or below-child glue is a referral
- rather than an answer, and that this referral MUST be able to contain
- the in-child or below-child glue, and that in outlying cases, only EDNS
- or TCP will be large enough to contain that data.
-
- 3 - Analysis
-
- 3.1. An instrumented protocol trace of a best case delegation response
- follows. Note that 13 servers are named, and 13 addresses are given.
- This query was artificially designed to exactly reach the 512 octet
- limit.
-
- ;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
- ;; QUERY SECTION:
- ;; [23456789.123456789.123456789.\
- 123456789.123456789.123456789.com A IN] ;; @80
-
- ;; AUTHORITY SECTION:
- com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
- com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
- com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
- com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
- com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
- com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
- com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
- com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
- com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
- com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
- com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
- com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
- com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
-
-
-
-
-
-
-
-
- Expires January 2007 [Page 5]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- ;; ADDITIONAL SECTION:
- A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
- B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
- C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
- D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
- E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
- F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
- G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
- H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
- I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
- J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
- K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
- L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
- M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
-
- ;; MSG SIZE sent: 80 rcvd: 512
-
- 3.2. For longer query names, the number of address records supplied will
- be lower. Furthermore, it is only by using a common parent name (which
- is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
- fit, due to the use of DNS compression pointers in the last 12
- occurances of the parent domain name. The following output from a
- response simulator demonstrates these properties.
-
- % perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
- a.dns.br requires 10 bytes
- b.dns.br requires 4 bytes
- c.dns.br requires 4 bytes
- d.dns.br requires 4 bytes
- # of NS: 4
- For maximum size query (255 byte):
- only A is considered: # of A is 4 (green)
- A and AAAA are considered: # of A+AAAA is 3 (yellow)
- preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
- For average size query (64 byte):
- only A is considered: # of A is 4 (green)
- A and AAAA are considered: # of A+AAAA is 4 (green)
- preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-
-
-
-
-
-
-
-
-
- Expires January 2007 [Page 6]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
- ns-ext.isc.org requires 16 bytes
- ns.psg.com requires 12 bytes
- ns.ripe.net requires 13 bytes
- ns.eu.int requires 11 bytes
- # of NS: 4
- For maximum size query (255 byte):
- only A is considered: # of A is 4 (green)
- A and AAAA are considered: # of A+AAAA is 3 (yellow)
- preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
- For average size query (64 byte):
- only A is considered: # of A is 4 (green)
- A and AAAA are considered: # of A+AAAA is 4 (green)
- preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
- (Note: The response simulator program is shown in Section 5.)
-
- Here we use the term "green" if all address records could fit, or
- "yellow" if two or more could fit, or "orange" if only one could fit, or
- "red" if no address record could fit. It's clear that without a common
- parent for nameserver names, much space would be lost. For these
- examples we use an average/common name size of 15 octets, befitting our
- assumption of GTLD-SERVERS.NET as our common parent name.
-
- We're assuming a medium query name size of 64 since that is the typical
- size seen in trace data at the time of this writing. If
- Internationalized Domain Name (IDN) or any other technology which
- results in larger query names be deployed significantly in advance of
- EDNS, then new measurements and new estimates will have to be made.
-
- 4 - Conclusions
-
- 4.1. The current practice of giving all nameserver names a common parent
- (such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
- responses and allows for more nameservers to be enumerated than would
- otherwise be possible, since the common parent domain name only appears
- once in a DNS message and is referred to via "compression pointers"
- thereafter.
-
- 4.2. If all nameserver names for a zone share a common parent, then it
- is operationally advisable to make all servers for the zone thus served
- also be authoritative for the zone of that common parent. For example,
- the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
- for the ROOT-SERVERS.NET. This is to ensure that the zone's servers
- always have the zone's nameservers' glue available when delegating, and
-
-
-
- Expires January 2007 [Page 7]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- will be able to respond with answers rather than referrals if a
- requester who wants that glue comes back asking for it. In this case
- the name server will likely be a "stealth server" -- authoritative but
- unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more
- information about stealth servers.
-
- 4.3. Thirteen (13) is the effective maximum number of nameserver names
- usable traditional (non-extended) DNS, assuming a common parent domain
- name, and given that implicit referral response truncation is
- undesirable in the average case.
-
- 4.4. Multi-homing of name servers within a protocol family is
- inadvisable since the necessary glue RRsets (A or AAAA) are atomically
- indivisible, and will be larger than a single resource record. Larger
- RRsets are more likely to lead to or encounter truncation.
-
- 4.5. Multi-homing of name servers across protocol families is less
- likely to lead to or encounter truncation, partly because multiprotocol
- clients are more likely to speak EDNS which can use a larger response
- size limit, and partly because the resource records (A and AAAA) are in
- different RRsets and are therefore divisible from each other.
-
- 4.6. Name server names which are at or below the zone they serve are
- more sensitive to referral response truncation, and glue records for
- them should be considered "less optional" than other glue records, in
- the assembly of referral responses.
-
- 4.7. If a zone is served by thirteen (13) name servers having a common
- parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
- single address record in some protocol family (e.g., an A RR), then all
- thirteen name servers or any subset thereof could multi-home in a second
- protocol family by adding a second address record (e.g., an AAAA RR)
- without reducing the reachability of the zone thus served.
-
- 5 - Source Code
-
- #!/usr/bin/perl
- #
- # SYNOPSIS
- # repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
- # if all queries are assumed to have a same zone suffix,
- # such as "jp" in JP TLD servers, specify it in -z option
- #
- use strict;
- use Getopt::Std;
-
-
-
- Expires January 2007 [Page 8]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- my ($sz_msg) = (512);
- my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
- my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
- my (%namedb, $name, $nssect, %opts, $optz);
- my $n_ns = 0;
-
- getopt('z', %opts);
- if (defined($opts{'z'})) {
- server_name_len($opts{'z'}); # just register it
- }
-
- foreach $name (@ARGV) {
- my $len;
- $n_ns++;
- $len = server_name_len($name);
- print "$name requires $len bytes\n";
- $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
- + $sz_rdlen + $len;
- }
- print "# of NS: $n_ns\n";
- arsect(255, $nssect, $n_ns, "maximum");
- arsect(64, $nssect, $n_ns, "average");
-
- sub server_name_len {
- my ($name) = @_;
- my (@labels, $len, $n, $suffix);
-
- $name =~ tr/A-Z/a-z/;
- @labels = split(/\./, $name);
- $len = length(join('.', @labels)) + 2;
- for ($n = 0; $#labels >= 0; $n++, shift @labels) {
- $suffix = join('.', @labels);
- return length($name) - length($suffix) + $sz_ptr
- if (defined($namedb{$suffix}));
- $namedb{$suffix} = 1;
- }
- return $len;
- }
-
- sub arsect {
- my ($sz_query, $nssect, $n_ns, $cond) = @_;
- my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
- $ansect = $sz_query + 1 + $sz_type + $sz_class;
- $space = $sz_msg - $sz_header - $ansect - $nssect;
- $n_a = atmost(int($space / $sz_rr_a), $n_ns);
-
-
-
- Expires January 2007 [Page 9]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- $n_a_aaaa = atmost(int($space
- / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
- $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
- / $sz_rr_aaaa), $n_ns);
- printf "For %s size query (%d byte):\n", $cond, $sz_query;
- printf " only A is considered: ";
- printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
- printf " A and AAAA are considered: ";
- printf "# of A+AAAA is %d (%s)\n",
- $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
- printf " preferred-glue A is assumed: ";
- printf "# of A is %d, # of AAAA is %d (%s)\n",
- $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
- }
-
- sub judge {
- my ($n, $n_ns) = @_;
- return "green" if ($n >= $n_ns);
- return "yellow" if ($n >= 2);
- return "orange" if ($n == 1);
- return "red";
- }
-
- sub atmost {
- my ($a, $b) = @_;
- return 0 if ($a < 0);
- return $b if ($a > $b);
- return $a;
- }
-
- 6 - Security Considerations
-
- The recommendations contained in this document have no known security
- implications.
-
- 7 - IANA Considerations
-
- This document does not call for changes or additions to any IANA
- registry.
-
- 8 - Acknowledgement
-
- The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
- for their valuable comments and suggestions.
-
-
-
-
- Expires January 2007 [Page 10]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- This work was supported by the US National Science Foundation (research
- grant SCI-0427144) and DNS-OARC.
-
- 9 - References
-
- [RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
- RFC1034, November 1987.
-
- [RFC1035] Mockapetris, P.V., "Domain names - Implementation and
- Specification", RFC1035, November 1987.
-
- [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
- Application and Support", RFC1123, October 1989.
-
- [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
- Changes (DNS NOTIFY)", RFC1996, August 1996.
-
- [RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
- RFC2181, July 1997.
-
- [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC2308, March 1998.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
- August 1999.
-
- [RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
- and Issues with IPV6 DNS", April 2006.
-
- 10 - Authors' Addresses
-
- Paul Vixie
- Internet Systems Consortium, Inc.
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 423 1301
- vixie@isc.org
-
- Akira Kato
- University of Tokyo, Information Technology Center
- 2-11-16 Yayoi Bunkyo
- Tokyo 113-8658, JAPAN
- +81 3 5841 2750
- kato@wide.ad.jp
-
-
-
-
- Expires January 2007 [Page 11]
-\f
- INTERNET-DRAFT August 2006 RESPSIZE
-
-
- Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors retain
- all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
- IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in this
- document or the extent to which any license under such rights might or
- might not be available; nor does it represent that it has made any
- independent effort to identify any such rights. Information on the
- procedures with respect to rights in RFC documents can be found in BCP
- 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an attempt
- made to obtain a general license or permission for the use of such
- proprietary rights by implementers or users of this specification can be
- obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary rights
- that may cover technology that may be required to implement this
- standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
- Acknowledgement
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
- Expires January 2007 [Page 12]
-\f
-
projects / thirdparty / bind9.git / commitdiff
