+++ /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
+++ /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
