From ba8f85b49c38af7bc2a9acdef5dcde2de008d25e Mon Sep 17 00:00:00 2001
From: peter <peter@FreeBSD.org>
Date: Sat, 12 Jul 2008 05:00:28 +0000
Subject: Flatten bind9 vendor work area
---
doc/draft/draft-baba-dnsext-acl-reqts-01.txt | 336 +++
doc/draft/draft-daigle-napstr-04.txt | 1232 ++++++++++
doc/draft/draft-danisch-dns-rr-smtp-03.txt | 1960 ++++++++++++++++
doc/draft/draft-dnsext-opcode-discover-02.txt | 241 ++
doc/draft/draft-durand-dnsop-dynreverse-00.txt | 240 ++
doc/draft/draft-ietf-dnsext-2929bis-01.txt | 928 ++++++++
doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt | 393 ++++
doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt | 674 ++++++
doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt | 1397 ++++++++++++
...t-ietf-dnsext-dnssec-2535typecode-change-06.txt | 442 ++++
.../draft-ietf-dnsext-dnssec-bis-updates-01.txt | 616 +++++
.../draft-ietf-dnsext-dnssec-experiments-01.txt | 784 +++++++
.../draft-ietf-dnsext-dnssec-online-signing-02.txt | 616 +++++
doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt | 896 ++++++++
.../draft-ietf-dnsext-dnssec-rsasha256-00.txt | 392 ++++
doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt | 839 +++++++
doc/draft/draft-ietf-dnsext-ds-sha256-05.txt | 504 +++++
doc/draft/draft-ietf-dnsext-ecc-key-07.txt | 928 ++++++++
doc/draft/draft-ietf-dnsext-interop3597-02.txt | 334 +++
...draft-ietf-dnsext-keyrr-key-signing-flag-12.txt | 560 +++++
doc/draft/draft-ietf-dnsext-mdns-43.txt | 1740 +++++++++++++++
doc/draft/draft-ietf-dnsext-nsec3-04.txt | 2352 ++++++++++++++++++++
doc/draft/draft-ietf-dnsext-nsid-01.txt | 840 +++++++
doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt | 464 ++++
doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt | 840 +++++++
doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt | 580 +++++
...-dnsext-signed-nonexistence-requirements-01.txt | 755 +++++++
.../draft-ietf-dnsext-tkey-renewal-mode-05.txt | 1292 +++++++++++
.../draft-ietf-dnsext-trustupdate-threshold-00.txt | 1501 +++++++++++++
.../draft-ietf-dnsext-trustupdate-timers-02.txt | 730 ++++++
doc/draft/draft-ietf-dnsext-tsig-sha-06.txt | 522 +++++
doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt | 1063 +++++++++
doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt | 1232 ++++++++++
...-ietf-dnsop-dnssec-operational-practices-08.txt | 2016 +++++++++++++++++
doc/draft/draft-ietf-dnsop-inaddr-required-07.txt | 396 ++++
.../draft-ietf-dnsop-ipv6-dns-configuration-06.txt | 1848 +++++++++++++++
doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt | 1682 ++++++++++++++
...aft-ietf-dnsop-ipv6-transport-guidelines-01.txt | 300 +++
...aft-ietf-dnsop-key-rollover-requirements-02.txt | 389 ++++
doc/draft/draft-ietf-dnsop-respsize-02.txt | 480 ++++
doc/draft/draft-ietf-dnsop-serverid-06.txt | 618 +++++
doc/draft/draft-ietf-enum-e164-gstn-np-05.txt | 1588 +++++++++++++
doc/draft/draft-ietf-ipv6-node-requirements-08.txt | 1200 ++++++++++
doc/draft/draft-ietf-secsh-dns-05.txt | 614 +++++
.../draft-ihren-dnsext-threshold-validation-00.txt | 519 +++++
doc/draft/draft-kato-dnsop-local-zones-00.txt | 295 +++
.../draft-park-ipv6-extensions-dns-pnp-00.txt | 1830 +++++++++++++++
doc/draft/update | 46 +
48 files changed, 42044 insertions(+)
create mode 100644 doc/draft/draft-baba-dnsext-acl-reqts-01.txt
create mode 100644 doc/draft/draft-daigle-napstr-04.txt
create mode 100644 doc/draft/draft-danisch-dns-rr-smtp-03.txt
create mode 100644 doc/draft/draft-dnsext-opcode-discover-02.txt
create mode 100644 doc/draft/draft-durand-dnsop-dynreverse-00.txt
create mode 100644 doc/draft/draft-ietf-dnsext-2929bis-01.txt
create mode 100644 doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
create mode 100644 doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
create mode 100644 doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
create mode 100644 doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
create mode 100644 doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
create mode 100644 doc/draft/draft-ietf-dnsext-ecc-key-07.txt
create mode 100644 doc/draft/draft-ietf-dnsext-interop3597-02.txt
create mode 100644 doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
create mode 100644 doc/draft/draft-ietf-dnsext-mdns-43.txt
create mode 100644 doc/draft/draft-ietf-dnsext-nsec3-04.txt
create mode 100644 doc/draft/draft-ietf-dnsext-nsid-01.txt
create mode 100644 doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
create mode 100644 doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
create mode 100644 doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
create mode 100644 doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
create mode 100644 doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
create mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
create mode 100644 doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
create mode 100644 doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
create mode 100644 doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
create mode 100644 doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
create mode 100644 doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
create mode 100644 doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
create mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
create mode 100644 doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
create mode 100644 doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
create mode 100644 doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
create mode 100644 doc/draft/draft-ietf-dnsop-respsize-02.txt
create mode 100644 doc/draft/draft-ietf-dnsop-serverid-06.txt
create mode 100644 doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
create mode 100644 doc/draft/draft-ietf-ipv6-node-requirements-08.txt
create mode 100644 doc/draft/draft-ietf-secsh-dns-05.txt
create mode 100644 doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
create mode 100644 doc/draft/draft-kato-dnsop-local-zones-00.txt
create mode 100644 doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
create mode 100644 doc/draft/update
(limited to 'doc/draft')
diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
new file mode 100644
index 0000000..1030e57
--- /dev/null
+++ b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
@@ -0,0 +1,336 @@
+
+
+
+
+Internet-Draft T. Baba
+Expires: March 11, 2004 NTT Data
+ September 11, 2003
+
+
+ Requirements for Access Control in Domain Name Systems
+ draft-baba-dnsext-acl-reqts-01.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 10 of RFC2026.
+
+ 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
+
+ Distribution of this memo is unlimited.
+
+ This Internet-Draft will expire on March 11, 2004.
+
+Abstract
+
+ This document describes the requirements for access control
+ mechanisms in the Domain Name System (DNS), which authenticate
+ clients and then allow or deny access to resource records in the
+ zone according to the access control list (ACL).
+
+1. Introduction
+
+ The Domain Name System (DNS) is a hierarchical, distributed, highly
+ available database used for bi-directional mapping between domain
+ names and IP addresses, for email routing, and for other information
+ [RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined
+ to authenticate the data in DNS and provide key distribution services
+ using SIG, KEY, and NXT resource records (RRs) [RFC2535].
+
+
+
+Baba Expires March 11, 2004 [Page 1]
+
+Internet-Draft DNS Access Control Requirements September 2003
+
+
+ At the 28th IETF Meeting in Houston in 1993, DNS security design team
+ started a discussion about DNSSEC and agreed to accept the assumption
+ that "DNS data is public". Accordingly, confidentiality for queries
+ or responses is not provided by DNSSEC, nor are any sort of access
+ control lists or other means to differentiate inquirers. However,
+ about ten years has passed, access control in DNS has been more
+ important than before. Currently, new RRs are proposed to add new
+ functionality to DNS such as ENUM [RFC2916]. Such new RRs may
+ contain private information. Thus, DNS access control will be
+ needed.
+
+ Furthermore, with DNS access control mechanism, access from
+ unauthorized clients can be blocked when they perform DNS name
+ resolution. Thus, for example, Denial of Service (DoS) attacks
+ against a server used by a closed user group can be prevented using
+ this mechanism if IP address of the server is not revealed by other
+ sources.
+
+ This document describes the requirements for access control
+ mechanisms in DNS.
+
+2. Terminology
+
+ AC-aware client
+ This is the client that understands the DNS access control
+ extensions. This client may be an end host which has a stub
+ resolver, or a cashing/recursive name server which has a
+ full-service resolver.
+
+ AC-aware server
+ This is the authoritative name server that understands the DNS
+ access control extensions.
+
+ ACE
+ An Access Control Entry. This is the smallest unit of access
+ control policy. It grants or denies a given set of access
+ rights to a set of principals. An ACE is a component of an ACL,
+ which is associated with a resource.
+
+ ACL
+ An Access Control List. This contains all of the access control
+ policies which are directly associated with a particular
+ resource. These policies are expressed as ACEs.
+
+ Client
+ A program or host which issues DNS requests and accepts its
+ responses. A client may be an end host or a cashing/recursive name
+ server.
+
+
+
+Baba Expires March 11, 2004 [Page 2]
+
+Internet-Draft DNS Access Control Requirements September 2003
+
+
+ RRset
+ All resource records (RRs) having the same NAME, CLASS and TYPE
+ are called a Resource Record Set (RRset).
+
+3. Requirements
+
+ This section describes the requirements for access control in DNS.
+
+3.1 Authentication
+
+3.1.1 Client Authentication Mechanism
+
+ The AC-aware server must identify AC-aware clients based on IP
+ address and/or domain name (user ID or host name), and must
+ authenticate them using strong authentication mechanism such as
+ digital signature or message authentication code (MAC).
+
+ SIG(0) RR [RFC2931] contains a domain name associated with sender's
+ public key in its signer's name field, and TSIG RR [RFC2845] also
+ contains a domain name associated with shared secret key in its key
+ name field. Each of these domain names can be a host name or a user
+ name, and can be used as a sender's identifier for access control.
+ Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
+ message authentication. These mechanisms can be used to authenticate
+ AC-aware clients.
+
+ Server authentication may be also provided.
+
+3.1.2 End-to-End Authentication
+
+ In current DNS model, caching/recursive name servers are deployed
+ between end hosts and authoritative name servers. Although
+ authoritative servers can authenticate caching/recursive name servers
+ using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
+ For end-to-end authentication, the mechanism for an end host to
+ discover the target authoritative name server and directly access to
+ it bypassing caching/recursive name servers is needed. For example,
+ an end host can get the IP addresses of the authoritative name
+ servers by retrieving NS RRs for the zone via local caching/recursive
+ name server.
+
+ In many enterprise networks, however, there are firewalls that block
+ all DNS packets other than those going to/from the particular
+ caching/recursive servers. To deal with this problem, one can
+ implement packet forwarding function on the caching/recursive servers
+ and enable end-to-end authentication via the caching/recursive
+ servers.
+
+
+
+
+Baba Expires March 11, 2004 [Page 3]
+
+Internet-Draft DNS Access Control Requirements September 2003
+
+
+3.1.3 Authentication Key Retrieval
+
+ Keys which are used to authenticate clients should be able to be
+ automatically retrieved. The KEY RR is used to store a public key
+ for a zone or a host that is associated with a domain name. SIG(0)
+ RR uses a public key in KEY RR for verifying the signature. If
+ DNSSEC is available, the KEY RR would be protected by the SIG RR.
+ KEY RR or newly defined RR can be used to automatic key retrieval.
+
+3.2 Confidentiality
+
+3.2.1 Data Encryption
+
+ To avoid disclosure to eavesdroppers, the response containing the
+ RRsets which are restricted to access from particular users should be
+ encrypted. Currently, no encryption mechanism is specified in DNS.
+ Therefore, new RRs should be defined for DNS message encryption.
+ Instead, IPsec [RFC2401] can be used to provide confidentiality if
+ name server and resolver can set up security associations dynamically
+ using IPsec API [IPSECAPI] when encryption is required.
+
+ In case encryption is applied, entire DNS message including DNS
+ header should be encrypted to hide information including error code.
+
+ Query encryption may be also provided for hiding query information.
+
+3.2.2 Key Exchange
+
+ If DNS message encryption is provided, automatic key exchange
+ mechanism should be also provided. [RFC2930] specifies a TKEY RR
+ that can be used to establish and delete shared secret keys used by
+ TSIG between a client and a server. With minor extensions, TKEY can
+ be used to establish shared secret keys used for message encryption.
+
+3.2.3 Caching
+
+ The RRset that is restricted to access from particular users must not
+ be cached. To avoid caching, the TTL of the RR that is restricted to
+ access should be set to zero during transit.
+
+3.3 Access Control
+
+3.3.1 Granularity of Access Control
+
+ Control of access on a per-user/per-host granularity must be
+ supported. Control of access to individual RRset (not just the
+ entire zone) must be also supported. However, SOA, NS, SIG, NXT,
+ KEY, and DS RRs must be publicly accessible to avoid unexpected
+ results.
+
+
+Baba Expires March 11, 2004 [Page 4]
+
+Internet-Draft DNS Access Control Requirements September 2003
+
+
+3.3.2 ACL Representation
+
+ Access Control List (ACL) format must be standardized so that both
+ the primary and secondary AC-aware servers can recognize the same
+ ACL. Although ACL may appear in or out of zone data, it must be
+ transferred to the secondary AC-aware server with associated zone
+ data. It is a good idea to contain ACL in zone data, because ACL can
+ be transferred with zone data using existing zone transfer mechanisms
+ automatically. However, ACL must not be published except for
+ authorized secondary master servers.
+
+ In zone data master files, ACL should be specified using TXT RRs or
+ newly defined RRs. In each access control entry (ACE), authorized
+ entities (host or user) must be described using domain name (host
+ name, user name, or IP address in in-addr.arpa/ip6.arpa format).
+ There may be other access control attributes such as access time.
+
+ It must be possible to create publicly readable entries, which may be
+ read even by unauthenticated clients.
+
+3.3.3 Zone/ACL Transfer
+
+ As mentioned above, ACL should be transferred from a primary AC-aware
+ server to a secondary AC-aware server with associated zone data.
+ When an AC-aware server receives a zone/ACL transfer request, the
+ server must authenticate the client, and should encrypt the zone
+ data and associated ACL during transfer.
+
+3.4 Backward/co-existence Compatibility
+
+ Any new protocols to be defined for access control in DNS must be
+ backward compatible with existing DNS protocol. AC-aware servers
+ must be able to process normal DNS query without authentication, and
+ must respond if retrieving RRset is publicly accessible.
+
+ Modifications to root/gTLD/ccTLD name servers are not allowed.
+
+4. Security Considerations
+
+ This document discusses the requirements for access control
+ mechanisms in DNS.
+
+5. Acknowledgements
+
+ This work is funded by the Telecommunications Advancement
+ Organization of Japan (TAO).
+
+ The author would like to thank the members of the NTT DATA network
+ security team for their important contribution to this work.
+
+
+Baba Expires March 11, 2004 [Page 5]
+
+Internet-Draft DNS Access Control Requirements September 2003
+
+
+6. 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.
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+ "Secret Key Transaction Authentication for DNS (TSIG)",
+ RFC 2845, May 2000.
+
+ [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
+ September 2000.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
+ RFC 2930, September 2000.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+ (SIG(0)s)", RFC 2931, September 2000.
+
+ [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
+ draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
+ Progress.
+
+
+Author's Address
+
+ Tatsuya Baba
+ NTT Data Corporation
+ Research and Development Headquarters
+ Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
+ Tokyo 104-0033, Japan
+
+ Tel: +81 3 3523 8081
+ Fax: +81 3 3523 8090
+ Email: babatt@nttdata.co.jp
+
+
+
+
+
+
+
+
+Baba Expires March 11, 2004 [Page 6]
diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt
new file mode 100644
index 0000000..fffa8a5
--- /dev/null
+++ b/doc/draft/draft-daigle-napstr-04.txt
@@ -0,0 +1,1232 @@
+
+
+Network Working Group L. Daigle
+Internet-Draft A. Newton
+Expires: August 15, 2004 VeriSign, Inc.
+ February 15, 2004
+
+
+ Domain-based Application Service Location Using SRV RRs and the
+ Dynamic Delegation Discovery Service (DDDS)
+ draft-daigle-napstr-04.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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 15, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This memo defines a generalized mechanism for application service
+ naming that allows service location without relying on rigid domain
+ naming conventions (so-called name hacks). The proposal defines a
+ Dynamic Delegation Discovery System (DDDS) Application to map domain
+ name, application service name, and application protocol to target
+ server and port, dynamically.
+
+
+
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 1]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . 4
+ 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . . 5
+ 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . . . . 5
+ 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . . . . 5
+ 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . . . . 5
+ 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . . . . 6
+ 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . . . . 6
+ 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1 Guidelines for Application Protocol Developers . . . . . . . 7
+ 3.1.1 Registration of application service and protocol tags . . . 7
+ 3.1.2 Definition of conditions for retry/failure . . . . . . . . . 8
+ 3.1.3 Server identification and handshake . . . . . . . . . . . . 8
+ 3.2 Guidelines for Domain Administrators . . . . . . . . . . . . 8
+ 3.3 Guidelines for Client Software Writers . . . . . . . . . . . 9
+ 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.2 Service Discovery within a Domain . . . . . . . . . . . . . 10
+ 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
+ 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 12
+ 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . . 12
+ 5. Motivation and Discussion . . . . . . . . . . . . . . . . . 14
+ 5.1 So, why not just SRV records? . . . . . . . . . . . . . . . 15
+ 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . . 15
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . 16
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
+ References . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
+ A. Application Service Location Application of DDDS . . . . . . 18
+ A.1 Application Unique String . . . . . . . . . . . . . . . . . 18
+ A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 18
+ A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 18
+ A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
+ A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
+ A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 20
+ A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 20
+ A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 20
+ B. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . 20
+ B.1 Finding the first (best) target . . . . . . . . . . . . . . 20
+ B.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 21
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 2]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+1. Introduction
+
+ This memo defines a generalized mechanism for application service
+ naming that allows service location without relying on rigid domain
+ naming conventions (so-called name hacks). The proposal defines a
+ Dynamic Delegation Discovery System (DDDS -- see [6]) Application to
+ map domain name, application service name, and application protocol
+ to target server and port, dynamically.
+
+ As discussed in Section 5, existing approaches to using DNS records
+ to dynamically determining the current host for a given application
+ service are limited in terms of the use cases supported. To address
+ some of the limitations, this document defines a DDDS Application to
+ map service+protocol+domain to specific server addresses using both
+ NAPTR [7] and SRV ([5]) DNS resource records. This can be viewed as
+ a more general version of the use of SRV and/or a very restricted
+ application of the use of NAPTR resource records.
+
+ 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]).
+
+2. Straightforward-NAPTR (S-NAPTR) Specification
+
+ The precise details of the specification of this DDDS application are
+ given in Appendix A. This section defines the usage of the DDDS
+ application.
+
+2.1 Key Terms
+
+ An "application service" is a generic term for some type of
+ application, indpendent of the protocol that may be used to offer it.
+ Each application service will be associated with an IANA-registered
+ tag. For example, instant messaging is a type of application
+ service, which can be implemented by many different application-layer
+ protocols, and the tag "IM" (used as an illustration here) could be
+ registered for it.
+
+ An "application protocol" is used to implement the application
+ service. These are also associated with IANA-registered tags. In
+ the case where multiple transports are available for the application,
+ separate tags should be defined for each transport.
+
+ The intention is that the combination of application service and
+ protocol tags should be specific enough that finding a known pair
+ (e.g., "IM:ProtC") is sufficient for a client to identify a server
+ with which it can communicate.
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 3]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ Some protocols support multiple application services. For example,
+ LDAP is an application protocol, and can be found supporting various
+ services (e.g., "whitepages", "directory enabled networking", etc).
+
+2.2 S-NAPTR DDDS Application Usage
+
+ As outlined in Appendix A, NAPTR records are used to store
+ application service+protocol information for a given domain.
+ Following the DDDS standard, these records are looked up, and the
+ rewrite rules (contained in the NAPTR records) are used to determine
+ the successive DNS lookups, until a desirable target is found.
+
+ For the rest of this section, refer to the set of NAPTR resource
+ records for example.com shown in the figure below.
+
+ example.com.
+ ;; order pref flags service regexp replacement
+ IN NAPTR 100 10 "" "WP:whois++" "" bunyip.example.
+ IN NAPTR 100 20 "s" "WP:ldap" "" _ldap._tcp.myldap.example.com.
+ IN NAPTR 200 10 "" "IM:protA" "" someisp.example.
+ IN NAPTR 200 30 "a" "IM:protB" "" myprotB.example.com.
+
+
+2.2.1 Ordering and Preference
+
+ A client retrieves all of the NAPTR records associated with the
+ target domain name (example.com, above). These are to be sorted in
+ terms of increasing ORDER, and increasing PREF within each ORDER.
+
+2.2.2 Matching and non-Matching NAPTR Records
+
+ Starting with the first sorted NAPTR record, the client examines the
+ SERVICE field to find a match. In the case of the S-NAPTR DDDS
+ application, that means a SERVICE field that includes the tags for
+ the desired application service and a supported application protocol.
+
+ If more than one NAPTR record matches, they are processed in
+ increasing sort order.
+
+2.2.3 Terminal and Non-Terminal NAPTR Records
+
+ A NAPTR record with an empty FLAG field is "non-terminal". That is,
+ more NAPTR RR lookups are to be performed. Thus, to process a NAPTR
+ record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
+ used as the target of the next DNS lookup -- for NAPTR RRs.
+
+ In S-NAPTR, the only terminal flags are "S" and "A". These are
+ called "terminal" NAPTR lookups because they denote the end of the
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 4]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ DDDS/NAPTR processing rules. In the case of an "S" flag, the
+ REPLACEMENT field is used as the target of a DNS query for SRV RRs,
+ and normal SRV processing is applied. In the case of an "A" flag, an
+ address record is sought for the REPLACEMENT field target (and the
+ default protocol port is assumed).
+
+2.2.4 S-NAPTR and Successive Resolution
+
+ As shown in the example NAPTR RR set above, it is possible to have
+ multiple possible targets for a single application service+protocol
+ pair. These are to be pursued in order until a server is
+ successfully contacted or all possible matching NAPTR records have
+ been successively pursued to terminal lookups and servers contacted.
+ That is, a client must backtrack and attempt other resolution paths
+ in the case of failure.
+
+ "Failure" is declared, and backtracking must be used when
+
+ o the designated remote server (host and port) fail to provide
+ appropriate security credentials for the *originating* domain
+
+ o connection to the designated remote server otherwise fails -- the
+ specifics terms of which are defined when an application protocol
+ is registered
+
+ o the S-NAPTR-designated DNS lookup fails to yield expected results
+ -- e.g., no A RR for an "A" target, no SRV record for an "S"
+ target, or no NAPTR record with appropriate application service
+ and protocol for a NAPTR lookup. Except in the case of the very
+ first NAPTR lookup, this last is a configuration error: the fact
+ that example.com has a NAPTR record pointing to "bunyip.example"
+ for the "WP:Whois++" service and protocol means the administrator
+ of example.com believes that service exists. If bunyip.example
+ has no "WP:Whois++" NAPTR record, the application client MUST
+ backtrack and try the next available "WP:Whois++" option from
+ example.com. As there is none, the whole resolution fails.
+
+ An application client first queries for the NAPTR RRs for the domain
+ of a named application service. The application client MUST select
+ one protocol to choose The PREF field of the NAPTR RRs may be used by
+ the domain administrator to The first DNS query is for the NAPTR RRs
+ in the original target domain (example.com, above).
+
+2.2.5 Clients Supporting Multiple Protocols
+
+ In the case of an application client that supports more than one
+ protocol for a given application service, it MUST pursue S-NAPTR
+ resolution completely for one protocol before trying another.j It MAY
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 5]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ choose which protocol to try first based on its own preference, or
+ from the PREF ranking in the first set of NAPTR records (i.e., those
+ for the target named domain). However, the chosen protocol MUST be
+ listed in that first NAPTR RR set.
+
+ That is, what the client MUST NOT do is start looking for one
+ protocol, observe that a successive NAPTR RR set supports another of
+ its preferred protocols, and continue the S-NAPTR resolution based on
+ that protocol. For example, even if someisp.example offers the "IM"
+ service with protocol "ProtB", there is no reason to believe it does
+ so on behalf of example.com (since there is no such pointer in
+ example.com's NAPTR RR set).
+
+3. Guidelines
+
+3.1 Guidelines for Application Protocol Developers
+
+ The purpose of S-NAPTR is to provide application standards developers
+ with a more powerful framework (than SRV RRs alone) for naming
+ service targets, without requiring each application protocol (or
+ service) standard to define a separate DDDS application.
+
+ Note that this approach is intended specifically for use when it
+ makes sense to associate services with particular domain names (e.g.,
+ e-mail addresses, SIP addresses, etc). A non-goal is having all
+ manner of label mapped into domain names in order to use this.
+
+ Specifically not addressed in this document is how to select the
+ domain for which the service+protocol is being sought. It is up to
+ other conventions to define how that might be used (e.g., instant
+ messaging standards can define what domain to use from IM URIs, how
+ to step down from foobar.example.com to example.com, and so on, if
+ that is applicable).
+
+ Although this document proposes a DDDS application that does not use
+ all the features of NAPTR resource records, it does not mean to imply
+ that DNS resolvers should fail to implement all aspects of the NAPTR
+ RR standard. A DDDS application is a client use convention.
+
+ The rest of this section outlines the specific elements that protocol
+ developers must determine and document in order to make use of S-
+ NAPTR.
+
+3.1.1 Registration of application service and protocol tags
+
+ Application protocol developers that wish to make use of S-NAPTR must
+ make provision to register any relevant application service and
+ application protocol tags, as described in Section 6.
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 6]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+3.1.2 Definition of conditions for retry/failure
+
+ One other important aspect that must be defined is the expected
+ behaviour for interacting with the servers that are reached via S-
+ NAPTR. Specifically, under what circumstances should the client
+ retry a target that was found via S-NAPTR? What should it consider a
+ failure that causes it to return to the S-NAPTR process to determine
+ the next serviceable target (a less preferred target)?
+
+ For example, if the client gets a "connection refused" from a server,
+ should it retry for some (protocol-dependent) period of time? Or,
+ should it try the next-preferred target in the S-NAPTR chain of
+ resolution? Should it only try the next-preferred target if it
+ receives a protocol-specific permanent error message?
+
+ The most important thing is to select one expected behaviour and
+ document it as part of the use of S-NAPTR.
+
+ As noted earlier, failure to provide appropriate credentials to
+ identify the server as being authoritative for the original taret
+ domain is always considered a failure condition.
+
+3.1.3 Server identification and handshake
+
+ As noted in Section 7, use of the DNS for server location increases
+ the importance of using protocol-specific handshakes to determine and
+ confirm the identity of the server that is eventually reached.
+
+ Therefore, application protocol developers using S-NAPTR should
+ identify the mechanics of the expected identification handshake when
+ the client connects to a server found through S-NAPTR.
+
+3.2 Guidelines for Domain Administrators
+
+ Although S-NAPTR aims to provide a "straightforward" application of
+ DDDS and use of NAPTR records, it is still possible to create very
+ complex chains and dependencies with the NAPTR and SRV records.
+
+ Therefore, domain administrators are called upon to use S-NAPTR with
+ as much restraint as possible, while still achieving their service
+ design goals.
+
+ The complete set of NAPTR, SRV and A RRs that are "reachable" through
+ the S-NAPTR process for a particular application service can be
+ thought of as a "tree". Each NAPTR RR retrieved points to more NAPTR
+ or SRV records; each SRV record points to several A record lookups.
+ Even though a particular client can "prune" the tree to use only
+ those records referring to application protocols supported by the
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 7]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ client, the tree could be quite deep, and retracing the tree to retry
+ other targets can become expensive if the tree has many branches.
+
+ Therefore,
+
+ o Fewer branches is better: for both NAPTR and SRV records, provide
+ different targets with varying preferences where appropriate
+ (e.g., to provide backup services, etc), but don't look for
+ reasons to provide more.
+
+ o Shallower is better: avoid using NAPTR records to "rename"
+ services within a zone. Use NAPTR records to identify services
+ hosted elsewhere (i.e., where you cannot reasonably provide the
+ SRV records in your own zone).
+
+
+3.3 Guidelines for Client Software Writers
+
+ To properly understand DDDS/NAPTR, an implementor must read [6].
+ However, the most important aspect to keep in mind is that, if one
+ target fails to work for the application, it is expected that the
+ application will continue through the S-NAPTR tree to try the (less
+ preferred) alternatives.
+
+4. Illustrations
+
+4.1 Use Cases
+
+ The basic intended use cases for which S-NAPTR has been developed
+ are:
+
+ o Service discovery within a domain. For example, this can be used
+ to find the "authoritative" server for some type of service within
+ a domain (see the specific example in Section 4.2).
+
+ o Multiple protocols. This is increasingly common as new
+ application services are defined. This includes the case of
+ instant messaging (a service) which can be offered with multiple
+ protocols (see Section 4.3).
+
+ o Remote hosting. Each of the above use cases applies within the
+ administration of a single domain. However, one domain operator
+ may elect to engage another organization to provide an application
+ service. See Section 4.4 for an example that cannot be served by
+ SRV records alone.
+
+
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 8]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+4.2 Service Discovery within a Domain
+
+ There are occasions when it is useful to be able to determine the
+ "authoritative" server for a given application service within a
+ domain. This is "discovery", because there is no a priori knowledge
+ as to whether or where the service is offered; it is therefore
+ important to determine the location and characteristics of the
+ offered service.
+
+ For example, there is growing discussion of having a generic
+ mechanism for locating the keys or certificates associated with
+ particular application (servers) operated in (or for) a particular
+ domain. Here's a hypothetical case for storing application key or
+ certificate data for a given domain. The premise is that some
+ credentials registry (CredReg) service has been defined to be a leaf
+ node service holding the keys/certs for the servers operated by (or
+ for) the domain. Furthermore, it is assumed that more than one
+ protocol is available to provide the service for a particular domain.
+ This DDDS-based approach is used to find the CredReg server that
+ holds the information.
+
+ Thus, the set of NAPTR records for thinkingcat.example might look
+ like this:
+
+ thinkingcat.example.
+ ;; order pref flags service regexp replacement
+ IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" theserver.thinkingcat.example.
+
+ Note that another domain, offering the same application service,
+ might offer it using a different set of application protocols:
+
+ anotherdomain.example.
+ ;; order pref flags service regexp replacement
+ IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" foo.anotherdomain.example.
+
+
+4.3 Multiple Protocols
+
+ As it stands, there are several different protocols proposed for
+ offering "instant message" services. Assuming that "IM" was
+ registered as an application service, this DDDS application could be
+ used to determine the available services for delivering to a target.
+
+ Two particular features of instant messaging should be noted:
+
+ 1. gatewaying is expected to bridge communications across protocols
+
+ 2. instant messaging servers are likely to be operated out of a
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 9]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ different domain than the instant messaging address, and servers
+ of different protocols may be offered by independent
+ organizations
+
+ For example, "thinkingcat.example" may support its own servers for
+ the "ProtA" instant messaging protocol, but rely on outsourcing from
+ "example.com" for "ProtC" and "ProtB" servers.
+
+ Using this DDDS-based approach, thinkingcat.example can indicate a
+ preference ranking for the different types of servers for the instant
+ messaging service, and yet the out-sourcer can independently rank the
+ preference and ordering of servers. This independence is not
+ achievable through the use of SRV records alone.
+
+ Thus, to find the IM services for thinkingcat.example, the NAPTR
+ records for thinkingcat.example are retrieved:
+
+ thinkingcat.example.
+ ;; order pref flags service regexp replacement
+ IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
+ IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com.
+ IN NAPTR 100 30 "s" "IM:ProtC" "" _ProtC._tcp.example.com.
+
+ and then the administrators at example.com can manage the preference
+ rankings of the servers they use to support the ProtB service:
+
+ _ProtB._tcp.example.com.
+ ;; Pref Weight Port Target
+ IN SRV 10 0 10001 bigiron.example.com
+ IN SRV 20 0 10001 backup.im.example.com
+ IN SRV 30 0 10001 nuclearfallout.australia-isp.example
+
+
+4.4 Remote Hosting
+
+ In the Instant Message hosting example in Section 4.3, the service
+ owner (thinkingcat.example) had to host pointers to the hosting
+ service's SRV records in the thinkingcat.example domain.
+
+ A better way to approach this is to have one NAPTR RR in the
+ thinkingcat.example domain pointing to all the hosted services, and
+ the hosting domain has NAPTR records for each service to map them to
+ whatever local hosts it chooses (and may change from time to time).
+
+
+
+
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 10]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ thinkingcat.example.
+ ;; order pref flags service regexp replacement
+ IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
+ IN NAPTR 100 20 "" "IM:ProtB:ProtC" "" thinkingcat.example.com.
+
+
+ and then the administrators at example.com can break out the
+ individual application protocols and manage the preference rankings
+ of the servers they use to support the ProtB service (as before):
+
+ thinkingcat.example.com.
+ ;; order pref flags service regexp replacement
+ IN NAPTR 100 10 "s" "IM:ProtC" "" _ProtC._tcp.example.com.
+ IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com.
+
+
+
+ _ProtC._tcp.example.com.
+ ;; Pref Weight Port Target
+ IN SRV 10 0 10001 bigiron.example.com
+ IN SRV 20 0 10001 backup.im.example.com
+ IN SRV 30 0 10001 nuclearfallout.australia-isp.example
+
+
+4.5 Sets of NAPTR RRs
+
+ Note that the above sections assumed that there was one service
+ available (via S-NAPTR) per domain. Often, that will not be the
+ case. Assuming thinkingcat.example had the CredReg service set up as
+ described in Section 4.2 and the instant messaging service set up as
+ described in Section 4.4, then a client querying for the NAPTR RR set
+ from thinkingcat.com would get the following answer:
+
+ thinkingcat.example.
+ ;; order pref flags service regexp replacement
+ IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
+ IN NAPTR 100 20 "" "IM:ProtB:ProtC:" "" thinkingcat.example.com.
+ IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.
+
+ Sorting them by increasing "ORDER", the client would look through the
+ SERVICE strings to determine if there was a NAPTR RR that matched the
+ application service it was looking for, with an application protocol
+ it could use. The first (lowest PREF) record that so matched is the
+ one the client would use to continue.
+
+4.6 Sample sequence diagram
+
+ Consider the example in Section 4.3. Visually, the sequence of steps
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 11]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ required for the client to reach the final server for a "ProtB"
+ service for IM for the thinkingcat.example domain is as follows:
+
+
+ Client NS for NS for
+ thinkingcat.example example.com backup.im.example.com
+ | | |
+ 1 -------->| | |
+ 2 <--------| | |
+ 3 ------------------------------>| |
+ 4 <------------------------------| |
+ 5 ------------------------------>| |
+ 6 <------------------------------| |
+ 7 ------------------------------>| |
+ 8 <------------------------------| |
+ 9 ------------------------------------------------->|
+ 10 <-------------------------------------------------|
+ 11 ------------------------------------------------->|
+ 12 <-------------------------------------------------|
+ (...)
+
+
+
+ 1. the name server (NS) for thinkingcat.example is reached with a
+ request for all NAPTR records
+
+ 2. the server responds with the NAPTR records shown in Section 4.3.
+
+ 3. the second NAPTR record matches the desired criteria; that has an
+ "s" flag and a replacement fields of "_ProtB._tcp.example.com".
+ So, the client looks up SRV records for that target, ultimately
+ making the request of the NS for example.com.
+
+ 4. the response includes the SRV records listed in Section 4.3.
+
+ 5. the client attempts to reach the server with the lowest PREF in
+ the SRV list -- looking up the A record for the SRV record's
+ target (bigiron.example.com).
+
+ 6. the example.com NS responds with an error message -- no such
+ machine!
+
+ 7. the client attempts to reach the second server in the SRV list,
+ and looks up the A record for backup.im.example.com
+
+ 8. the client gets the A record with the IP address for
+ backup.im.example.com from example.com's NS.
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 12]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ 9. the client connects to that IP address, on port 10001 (from the
+ SRV record), using ProtB over tcp.
+
+ 10. the server responds with an "OK" message.
+
+ 11. the client uses ProtB to challenge that this server has
+ credentials to operate the service for the original domain
+ (thinkingcat.example)
+
+ 12. the server responds, and the rest is IM.
+
+
+5. Motivation and Discussion
+
+ Increasingly, application protocol standards are using domain names
+ to identify server targets, and stipulating that clients should look
+ up SRV resource records to determine the host and port providing the
+ server. This enables a distinction between naming an application
+ service target and actually hosting the server. It also increases
+ flexibility in hosting the target service:
+
+ o the server may be operated by a completely different organization
+ without having to list the details of that organization's DNS
+ setup (SRVs)
+
+ o multiple instances can be set up (e.g., for load balancing or
+ secondaries)
+
+ o it can be moved from time to time without disrupting clients'
+ access, etc.
+
+ This is quite useful, but Section 5.1 outlines some of the
+ limitations inherent in the approach.
+
+ That is, while SRV records can be used to map from a specific service
+ name and protocol for a specific domain to a specific server, SRV
+ records are limited to one layer of indirection, and are focused on
+ server administration rather than on application naming. And, while
+ the DDDS specification and use of NAPTR allows multiple levels of
+ redirection before locating the target server machine with an SRV
+ record, this proposal requires only a subset of NAPTR strictly bound
+ to domain names, without making use of the REGEXP field of NAPTR.
+ These restrictions make the client's resolution process much more
+ predictable and efficient than with some potential uses of NAPTR
+ records. This is dubbed "S-NAPTR" -- a "S"traightforward use of
+ NAPTR records.
+
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 13]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+5.1 So, why not just SRV records?
+
+ An expected question at this point is: this is so similar in
+ structure to SRV records, why are we doing this with DDDS/NAPTR?
+
+ Limitations of SRV include:
+
+ o SRV provides a single layer of indirection -- the outcome of an
+ SRV lookup is a new domain name for which the A RR is to be found.
+
+ o the purpose of SRV is focused on individual server administration,
+ not application naming: as stated in [5] "The SRV RR allows
+ administrators to use several servers for a single domain, to move
+ services from host to host with little fuss, and to designate some
+ hosts as primary servers for a service and others as backups."
+
+ o target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
+ "tcp") in a given domain. The definition of these terms implies
+ specific things (e.g., that protocol should be one of UDP or TCP)
+ without being precise. Restriction to UDP and TCP is insufficient
+ for the uses described here.
+
+ The basic answer is that SRV records provide mappings from protocol
+ names to host and port. The use cases described herein require an
+ additional layer -- from some service label to servers that may in
+ fact be hosted within different administrative domains. We could
+ tweak SRV to say that the next lookup could be something other than
+ an address record, but that is more complex than is necessary for
+ most applications of SRV.
+
+5.2 So, why not just NAPTR records?
+
+ That's a trick question. NAPTR records cannot appear in the wild --
+ see [6]. They must be part of a DDDS application.
+
+ The purpose here is to define a single, common mechanism (the DDDS
+ application) to use NAPTR when all that is desired is simple DNS-
+ based location of services. This should be easy for applications to
+ use -- some simple IANA registrations and it's done.
+
+ Also, NAPTR has very powerful tools for expressing "rewrite" rules.
+ That power (==complexity) makes some protocol designers and service
+ administrators nervous. The concern is that it can translate into
+ unintelligible, noodle-like rule sets that are difficult to test and
+ administer.
+
+ This proposed DDDS application specifically uses a subset of NAPTR's
+ abilities. Only "replacement" expressions are allowed, not "regular
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 14]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ expressions".
+
+6. IANA Considerations
+
+ This document calls for 2 IANA registries: one for application
+ service tags, and one for application protocol tags.
+
+ Application service and protocol tags should be defined in an RFC
+ (unless the "x-" experimental form is used, in which case they are
+ unregistered). There are no restrictions placed on the tags other
+ than that they must conform with the syntax defined below (Appendix
+ A.5). The IANA registries should list the tags and the RFC that
+ defines their use.
+
+7. Security Considerations
+
+ The security of this approach to application service location is only
+ as good as the security of the DNS servers along the way. If any of
+ them is compromised, bogus NAPTR and SRV records could be inserted to
+ redirect clients to unintended destinations. This problem is hardly
+ unique to S-NAPTR (or NAPTR in general).
+
+ To protect against DNS-vectored attacks, applications should define
+ some form of end-to-end authentication to ensure that the correct
+ destination has been reached. Many application protocols such as
+ HTTPS, BEEP, IMAP, etc... define the necessary handshake mechansims
+ to accomplish this task.
+
+ The basic mechanism works in the following way:
+
+ 1. During some portion of the protocol handshake, the client sends
+ to the server the original name of the desired destination (i.e.
+ no transformations that may have resulted from NAPTR
+ replacements, SRV targets, or CNAME changes). In certain cases
+ where the application protocol does not have such a feature but
+ TLS may be used, it is possible to use the "server_name" TLS
+ extension.
+
+ 2. The server sends back to the client a credential with the
+ appropriate name. For X.509 certificates, the name would either
+ be in the subjectDN or subjectAltName fields. For Kerberos, the
+ name would be a service principle name.
+
+ 3. Using the matching semantics defined by the application protocol,
+ the client compares the name in the credential with the name sent
+ to the server.
+
+ 4. If the names match, there is reasonable assurance that the
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 15]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ correct end point has been reached.
+
+ It is important to note that this document does not define either the
+ handshake mechanism, the specific credenential naming fields, nor the
+ name matching semantics. Definitions of S-NAPTR for particular
+ application protocols MUST define these.
+
+8. Acknowledgements
+
+ Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
+ discussion and input that has (hopefully!) provoked clarifying
+ revisions of this document.
+
+References
+
+ [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+ Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [4] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+ One: The Comprehensive DDDS", RFC 3401, October 2002.
+
+ [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+ Three: The Domain Name System (DNS) Database", RFC 3403, October
+ 2002.
+
+ [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+ Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
+ 2002.
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 16]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+Authors' Addresses
+
+ Leslie Daigle
+ VeriSign, Inc.
+ 21355 Ridgetop Circle
+ Dulles, VA 20166
+ US
+
+ EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
+
+
+ Andrew Newton
+ VeriSign, Inc.
+ 21355 Ridgetop Circle
+ Dulles, VA 20166
+ US
+
+ EMail: anewton@verisignlabs.com
+
+Appendix A. Application Service Location Application of DDDS
+
+ This section defines the DDDS application, as described in [6].
+
+A.1 Application Unique String
+
+ The Application Unique String is domain label for which an
+ authoritative server for a particular service is sought.
+
+A.2 First Well Known Rule
+
+ The "First Well Known Rule" is identity -- that is, the output of the
+ rule is the Application Unique String, the domain label for which the
+ authoritative server for a particular service is sought.
+
+A.3 Expected Output
+
+ The expected output of this Application is the information necessary
+ to connect to authoritative server(s) (host, port, protocol) for an
+ application service within a given a given domain.
+
+A.4 Flags
+
+ This DDDS Application uses only 2 of the Flags defined for the
+ URI/URN Resolution Application ([8]): "S" and "A". No other Flags
+ are valid.
+
+ Both are for terminal lookups. This means that the Rule is the last
+ one and that the flag determines what the next stage should be. The
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 17]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ "S" flag means that the output of this Rule is a domain label for
+ which one or more SRV [5] records exist. "A" means that the output
+ of the Rule is a domain name and should be used to lookup address
+ records for that domain.
+
+ Consistent with the DDDS algorithm, if the Flag string is empty the
+ next lookup is for another NAPTR record (for the replacement target).
+
+A.5 Service Parameters
+
+ Service Parameters for this Application take the form of a string of
+ characters that follow this ABNF ([3]):
+
+ service-parms = [ [app-service] *(":" app-protocol)]
+ app-service = experimental-service / iana-registered-service
+ app-protocol = experimental-protocol / iana-registered-protocol
+ experimental-service = "x-" 1*30ALPHANUMSYM
+ experimental-protocol = "x-" 1*30ALPHANUMSYM
+ iana-registered-service = ALPHA *31ALPHANUMSYM
+ iana-registered-protocol = ALPHA *31ALPHANUM
+ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
+ DIGIT = %x30-39 ; 0-9
+ SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
+ ALPHANUMSYM = ALPHA / DIGIT / SYM
+ ; The app-service and app-protocol tags are limited to 32
+ ; characters and must start with an alphabetic character.
+ ; The service-parms are considered case-insensitive.
+
+ Thus, the Service Parameters may consist of an empty string, just an
+ app-service, or an app-service with one or more app-protocol
+ specifications separated by the ":" symbol.
+
+ Note that this is similar to, but not the same as the syntax used in
+ the URI DDDS application ([8]). The DDDS DNS database requires each
+ DDDS application to define the syntax of allowable service strings.
+ The syntax here is expanded to allow the characters that are valid in
+ any URI scheme name (see [1]). Since "+" (the separator used in the
+ RFC3404 service parameter string) is an allowed character for URI
+ scheme names, ":" is chosen as the separator here.
+
+A.5.1 Application Services
+
+ The "app-service" must be a registered service [this will be an IANA
+ registry; this is not the IANA port registry, because we want to
+ define services for which there is no single protocol, and we don't
+ want to use up port space for nothing].
+
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 18]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+A.5.2 Application Protocols
+
+ The protocol identifiers that are valid for the "app-protocol"
+ production are any standard, registered protocols [IANA registry
+ again -- is this the list of well known/registered ports?].
+
+A.6 Valid Rules
+
+ Only substitution Rules are permitted for this application. That is,
+ no regular expressions are allowed.
+
+A.7 Valid Databases
+
+ At present only one DDDS Database is specified for this Application.
+ [7] specifies a DDDS Database that uses the NAPTR DNS resource record
+ to contain the rewrite rules. The Keys for this database are encoded
+ as domain-names.
+
+ The First Well Known Rule produces a domain name, and this is the Key
+ that is used for the first lookup -- the NAPTR records for that
+ domain are requested.
+
+ DNS servers MAY interpret Flag values and use that information to
+ include appropriate NAPTR, SRV or A records in the Additional
+ Information portion of the DNS packet. Clients are encouraged to
+ check for additional information but are not required to do so. See
+ the Additional Information Processing section of [7] for more
+ information on NAPTR records and the Additional Information section
+ of a DNS response packet.
+
+Appendix B. Pseudo pseudocode for S-NAPTR
+
+B.1 Finding the first (best) target
+
+ Assuming the client supports 1 protocol for a particular application
+ service, the following pseudocode outlines the expected process to
+ find the first (best) target for the client, using S-NAPTR.
+
+
+ target = [initial domain]
+ naptr-done = false
+
+ while (not naptr-done)
+ {
+ NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
+ [sort NAPTR-RRset by ORDER, and PREF within each ORDER]
+ rr-done = false
+ cur-rr = [first NAPTR RR]
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 19]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ while (not rr-done)
+ if ([SERVICE field of cur-rr contains desired application
+ service and application protocol])
+ rr-done = true
+ target= [REPLACEMENT target of NAPTR RR]
+ else
+ cur-rr = [next rr in list]
+
+ if (not empty [FLAG in cur-rr])
+ naptr-done = true
+ }
+
+ port = -1
+
+ if ([FLAG in cur-rr is "S"])
+ {
+ SRV-RRset = [DNSlookup of SRV RRs for target]
+ [sort SRV-RRset based on PREF]
+ target = [target of first RR of SRV-RRset]
+ port = [port in first RR of SRV-RRset]
+ }
+
+ ; now, whether it was an "S" or an "A" in the NAPTR, we
+ ; have the target for an A record lookup
+
+ host = [DNSlookup of target]
+
+ return (host, port)
+
+
+
+B.2 Finding subsequent targets
+
+ The pseudocode in Appendix B is crafted to find the first, most
+ preferred, host-port pair for a particular application service an
+ protocol. If, for any reason, that host-port pair did not work
+ (connection refused, application-level error), the client is expected
+ to try the next host-port in the S-NAPTR tree.
+
+ The pseudocode above does not permit retries -- once complete, it
+ sheds all context of where in the S-NAPTR tree it finished.
+ Therefore, client software writers could
+
+ o entwine the application-specific protocol with the DNS lookup and
+ RRset processing described in the pseudocode and continue the S-
+ NAPTR processing if the application code fails to connect to a
+ located host-port pair;
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 20]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+ o use callbacks for the S-NAPTR processing;
+
+ o use an S-NAPTR resolution routine that finds *all* valid servers
+ for the required application service and protocol from the
+ originating domain, and provides them in sorted order for the
+ application to try in order.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 21]
+
+Internet-Draft draft-daigle-napstr-04 February 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton Expires August 15, 2004 [Page 22]
+
diff --git a/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/doc/draft/draft-danisch-dns-rr-smtp-03.txt
new file mode 100644
index 0000000..4a01d91
--- /dev/null
+++ b/doc/draft/draft-danisch-dns-rr-smtp-03.txt
@@ -0,0 +1,1960 @@
+
+
+
+INTERNET-DRAFT Hadmut Danisch
+Category: Experimental Oct 2003
+Expires: Apr 1, 2004
+
+ The RMX DNS RR and method for lightweight SMTP sender authorization
+ draft-danisch-dns-rr-smtp-03.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 10 of RFC2026.
+
+ 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
+
+ This memo introduces a new authorization scheme for SMTP e-mail
+ transport. It is designed to be a simple and robust protection
+ against e-mail fraud, spam and worms. It is based solely on
+ organisational security mechanisms and does not require but still
+ allow use of cryptography. This memo also focuses on security and
+ privacy problems and requirements in context of spam defense. In
+ contrast to prior versions of the draft a new RR type is not
+ required anymore.
+
+
+
+
+
+
+
+
+
+
+
+
+Hadmut Danisch Experimental [Page 1]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ Table of Contents
+
+
+1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
+2. Problem and threat description . . . . . . . . . . . . . . . . . 4
+ 2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4
+ 2.1.1 Definition of sender forgery . . . . . . . . . . . 4
+ 2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5
+ 2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5
+ 2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6
+ 2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6
+ 2.4. Shortcomings of cryptographical approaches . . . . . . . . 7
+3. A DNS based sender address verification . . . . . . . . . . . . 7
+ 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2. Envelope vs. header sender address . . . . . . . . . . . . 9
+ 3.3. Domain part vs. full sender address . . . . . . . . . . . 9
+4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10
+ 4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10
+ 4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11
+5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11
+ 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11
+ 5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12
+ 5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13
+ 5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14
+ 5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15
+ 5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15
+ 5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16
+6. Optional and experimental entry types . . . . . . . . . . . . . 16
+ 6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16
+ 6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16
+ 6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17
+ 6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17
+7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 7.1. Alternative encoding as TXT records . . . . . . . . . . . 17
+ 7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17
+ 7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18
+ 7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18
+ 7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18
+ 7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18
+ 7.2.5 Encoding of unused and full query . . . . . . . . . 19
+ 7.2.6 Additional Records . . . . . . . . . . . . . . . . 19
+8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19
+
+
+
+Hadmut Danisch Experimental [Page 2]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20
+10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20
+ 10.1. Problem description . . . . . . . . . . . . . . . . . . . 20
+ 10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21
+ 10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21
+11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
+ 11.1. Draft specific considerations . . . . . . . . . . . . . . 22
+ 11.1.1 Authentication strength . . . . . . . . . . . . . 22
+ 11.1.2 Where Authentication and Authorization end . . . . 22
+ 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23
+ 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25
+ 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25
+ 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25
+ 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26
+ 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26
+ 11.2. General Considerations about spam defense . . . . . . . . 27
+ 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27
+ 11.2.2 Content based Denial of Service attacks . . . . . 27
+12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28
+ 12.1. Draft specific considerations . . . . . . . . . . . . . . 28
+ 12.1.1 No content leaking . . . . . . . . . . . . . . . . 28
+ 12.1.2 Message reception and sender domain . . . . . . . 28
+ 12.1.3 Network structure . . . . . . . . . . . . . . . . 29
+ 12.1.4 Owner information distribution . . . . . . . . . . 29
+ 12.2. General Considerations about spam defense . . . . . . . . 29
+ 12.2.1 Content leaking of content filters . . . . . . . . 29
+ 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30
+13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30
+ 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30
+ 13.1.1 Compatibility with old mail receivers . . . . . . 30
+ 13.1.2 Compatibility with old mail senders . . . . . . . 30
+ 13.1.3 Compatibility with old DNS clients . . . . . . . . 30
+ 13.1.4 Compatibility with old DNS servers . . . . . . . . 30
+ 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31
+14. General considerations about fighting spam . . . . . . . . . . 31
+ 14.1. The economical problem . . . . . . . . . . . . . . . . . 31
+ 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32
+ 14.3. The network structure problem . . . . . . . . . . . . . . 33
+ 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33
+ 14.5. The identity problem . . . . . . . . . . . . . . . . . . 33
+ 14.6. The multi-legislation problem . . . . . . . . . . . . . . 34
+Implementation and further Information . . . . . . . . . . . . . . . 34
+References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
+Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
+Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35
+
+
+
+
+
+
+Hadmut Danisch Experimental [Page 3]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+1. General Issues
+
+ 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. Problem and threat description
+
+2.1. Mail sender forgery
+
+ The amount of e-mails with forged sender addresses has dramatically
+ increased. As a consequence, damages and annoyances caused by such
+ e-mails increased as well. In the majority of examined e-mails the
+ domain name of the envelope sender address was forged, and the e-
+ mail was sent from an IP address which does not belong to a network
+ used by the actual owner of the domain.
+
+2.1.1. Definition of sender forgery
+
+ As discussions, comments to prior versions of this draft, and
+ different approaches to stop forgery showed, different perceptions
+ of "mail forgery" exist. For example, there are mechanisms to
+ verify e-mail addresses for mailing lists, web servers, or to stop
+ spam, which do send a message with a random number to the given
+ address and expect the user to send a reply. Here, someone is
+ considered to be allowed to use a particular e-mail address, if and
+ only if he is able to receive informations sent to this address,
+ and is able to reply to such a message. While this definition
+ appears to be quite plausible and natural, it can't be used for a
+ simple technical solution. Sending back a challenge and expecting a
+ reply is simply too much overhead and time delay, and not every
+ authorized sender is able or willing to reply (e.g. because he went
+ offline or is not a human).
+
+ Within the scope of this memo, sender forgery means that the
+ initiator of an e-mail transfer (which is the original sender in
+ contrast to relays) uses a sender address which he was not
+ authorized to use. Being authorized to use an address means that
+ the owner (administrator) of the internet domain has given
+ permission, i.e. agrees with the use of the address by that
+ particular sender. This memo will cover both the permission of the
+ full e-mail address and the domain part only for simplicity.
+
+ Within context of Internet and SMTP, the sender address usually
+ occurs twice, once as the envelope sender address in SMTP, and once
+ as the address given in the RFC822 mail header. While the following
+ considerations apply to both addresses in principle, it is
+ important to stress that both addresses have distinct semantics and
+
+
+
+Hadmut Danisch Experimental [Page 4]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ are not neccessarily the same. The envelope address identifies the
+ initiator of the transport, while the header identifies the author
+ of the message content. Since this memo deals with the message
+ transport only and completely ignores the message content, the
+ method should naturally be applied to the envelope sender address.
+
+2.1.2. Spam
+
+ A common and well known problem is the dramatic increase of
+ unsolicited e-mail, commonly called "spam". Again, the majority of
+ examined e-mails had forged sender addresses. The abused domains
+ were mainly those of common webmailers as hotmail or yahoo, or
+ well-known companies.
+
+ Unfortunately, there is no accurate definition of spam availabe
+ yet, and neither are the concise technical criterions to filter or
+ block spam with technical mechanisms. There are efforts to design
+ content based filters, but these filters are expensive in
+ calculation time (and sometimes money), and they do not reliably
+ provide predictable results. Usually they give false positives
+ and/or require user interaction. Content filters in general suffer
+ from a design problem described later in this memo. Therefore,
+ this proposal does not use the content based approach to block
+ spam.
+
+ As analysis of spam messages showed, most of spam messages were
+ sent with forged envelope sender addresses. This has mainly three
+ reasons. The first reason is, that spam senders usually do not
+ want to be contacted by e-mail. The second reason is, that they do
+ not want to be blacklisted easily. The third reason is, that spam
+ is or is going to be unlawful in many countries, and the sender
+ does not want to reveal his identity. Therefore, spam is considered
+ to be a special case of sender forgery.
+
+2.1.3. E-Mail Worms
+
+ Another example of sender forgery is the reproduction of e-mail
+ worms. Most worms do choose random sender addresses, e.g. using
+ the addresses found in mailboxes on the infected system. In most
+ cases analyzed by the author, the e-mails sent by the reproduction
+ process can also be categorized as forged, since the infected
+ system would under normal circumstances not be authorized to send
+ e-mails with such e-mail addresses. So forgery does not require a
+ malicious human to be directly involved. This memo covers any kind
+ of e-mail sender address forgery, included those generated by
+ malicious software.
+
+2.1.4. E-Mail spoofing and fraud
+
+
+
+Hadmut Danisch Experimental [Page 5]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ Forging e-mail sender addresses for fraud or other kinds of
+ deception ("human engineering") has also dramatically increased.
+ There are many known cases where single or mass e-mails were sent
+ with wrong sender addresses, pretending to come from service
+ provider, software manufacturers etc., and asking the receiver to
+ install any software or patches, or to reply with any confidential
+ information. The Internet is becoming more and more a scene of
+ crime, and so are it's services, including e-mail. It is obvious
+ that crime based on e-mail is eased by the fact that SMTP allows
+ arbitrary sender address spoofing.
+
+2.2. Indirect damage caused by forgery
+
+ As observed by the author, mass mails and worms with forged sender
+ addresses can cause a severe damage for the real owner of the
+ abused sender addresses. If a sender A is sending an e-mail to the
+ receiver B, pretending to be C by using a sender address of C's
+ domain, then C has currently no chance to prevent this, since C's
+ machines and software are not involved in any way in the delivery
+ process between A and B. B will nevertheless send any error
+ messages (virus/spam alert, "no such user", etc.) to C, erroneously
+ assuming that the message was sent by C. The author found several
+ cases where this flood of error messages caused a severe denial of
+ service or a dramatic increase of costs, e.g. when C was
+ downloading the e-mail through expensive or low bandwidth
+ connections (e.g. modem or mobile phones), or where disk space was
+ limited. The author examined mass mailings, where several tens or
+ hundreds of thousands of messages were sent to several addresses
+ around the world, where these messages caused only annoyance. But
+ since several thousands of these addresses were invalid or didn't
+ accept the message, the owner of the DNS domain which was abused by
+ the spammer to forge sender addresses was flooded for several
+ months with thousands of error messages, jamming the e-mail system
+ and causing severe costs and damages.
+
+ As a consequence, when A sends a message to B, pretending to be C,
+ there must be any mechanism to allow C to inform B about the fact,
+ that A is not authorized to use C as a sender address. This is what
+ this memo is about.
+
+2.3. Technical problem analysis
+
+ Why does e-mail forgery actually exist? Because of the lack of the
+ Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
+ authentication, authorisation, or verification. This protocol was
+ designed at a time where security was not an issue. Efforts have
+ been made to block forged e-mails by requiring the sender address
+ domain part to be resolvable. This method provides protection from
+
+
+
+Hadmut Danisch Experimental [Page 6]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ e-mails with non-existing sender domains, and indeed, for some time
+ it blocked most spam e-mails. However, since attackers and spam
+ senders began to abuse existing domain names, this method was
+ rendered ineffective.
+
+2.4. Shortcomings of cryptographical approaches
+
+ At a first glance, the problem of sender address forgery might
+ appear to be solvable with cryptographic methods such as challenge
+ response authentications or digital signatures. A deeper analysis
+ shows that only a small, closed user group could be covered with
+ cryptographical methods. Any method used to stop spam forgery must
+ be suitable to detect forgery not only for a small number of
+ particular addresses, but for all addresses on the world. An
+ attacker does not need to know the secrets belonging to a
+ particular address. It is sufficient to be able to forge any
+ address and thus to know any secret key. Since there are several
+ hundreds of millions of users, there will always be a large amount
+ of compromised keys, thus spoiling any common cryptographic method.
+ Furthermore, cryptography has proven to be far too complicated and
+ error prone to be commonly administered and reliably implemented.
+ Many e-mail and DNS administrators do not have the knowledge
+ required to deal with cryptographic mechanisms. Many legislations
+ do not allow the general deployment of cryptography and a directory
+ service with public keys. For these reasons, cryptography is
+ applicable only to a small and closed group of users, but not to
+ all participants of the e-mail service.
+
+3. A DNS based sender address verification
+
+3.1. Overview
+
+ To gain improvement in e-mail authenticity while keeping as much
+ SMTP compatibility as possible, a method is suggested which doesn't
+ change SMTP at all.
+
+ The idea is to store informations about how to verify who is
+ authorized to transmit e-mails through SMTP with a particular
+ sender address (either full address or - for simplicity - only the
+ domain part of the address) in a directory service, which is
+ currently the DNS. To be precise, the verification consists of two
+ steps, the classical pair of authentication and authorization:
+
+ The first step is the authentication. While several methods are
+ possible to perform authentication (see below), the most important
+ and robust method is the verification of the sender's IP address.
+ This is done implicitely by TCP/IP and the TCP sequence number. The
+ authenticated identity is the IP address. It has to be stressed
+
+
+
+Hadmut Danisch Experimental [Page 7]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ that this TCP/IP "authentication" is a weak authentication and
+ vulnerable to several attacks. It is nevertheless sufficient for
+ this purpose, especially for blocking spam. It doesn't take any
+ implementation and it doesn't cost: It is already there, it is a
+ functionality of TCP/IP. An incoming SMTP connection based on
+ TCP/IP already carries the sender's IP address without any
+ modification of SMTP. See below (section Entry types) for more
+ details about authentication methods.
+
+ The second step is the authorization. It is based on the identity
+ given by the previous authentication step, e.g. the IP address of
+ the originator of the incoming SMTP connection, and on the
+ envelope sender address. The mechanism proposed in this memo
+ answers the question "Is that particular sender (IP address,...)
+ allowed to send with that sender address" by querying and
+ processing informations stored in a directory service, which is
+ DNS.
+
+ When the sender has issued the "MAIL FROM:" SMTP command, the
+ receiving mail transfer agent (MTA) can - and modern MTAs do -
+ perform some authorization checks, e.g. run a local rule database
+ or check whether the sender domain is resolvable.
+
+ The suggested method is to let the DNS server for the sender domain
+ provide informations about who - this means for example which IP
+ address - is authorized to use an address or a domain as a part of
+ it. After receiving the "MAIL FROM:" SMTP command, the receiving
+ MTA can verify, whether e. g. the IP address of the sending MTA is
+ authorized to send mails with this domain name. Therefore, a list
+ of entries with authorized IP addresses or other informations is
+ provided by the authoritative DNS server of that domain. The entry
+ types are described in the subsequent chapters. Some of these
+ methods are
+
+ - An IPv4 or IPv6 network address and mask
+ - A fully qualified domain name referring to an A record
+ - A fully qualified domain name referring to an APL record
+
+ RMX records of these types would look like this:
+
+ somedomain.de. IN RMX ipv4:10.0.0.0/8
+ rmxtest.de. IN RMX host:relay.provider.com
+ danisch.de. IN RMX apl:relays.rackland.de
+ relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
+
+ where the machine with the example address 213.133.101.23 and the
+ machines in the example subnet 1.2.3.0/24 are the only machines
+ allowed to send e-mails with an envelope sender address of domain
+
+
+
+Hadmut Danisch Experimental [Page 8]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ danisch.de. Since the APL records do not necessarily belong to the
+ same domain or zone table as the RMX records, this easily allows to
+ refer to APL records defined by someone else, e.g. the internet
+ access or server hosting provider, thus reducing administrative
+ overhead to a minimum. In the example given above, the domain
+ danisch.de and several other domains are hosted by the service
+ provider Rackland. So if the relay structure of Rackland is
+ modified, only the zone of rackland.de needs to be modified. The
+ domain owners don't need to care about such details.
+
+3.2. Envelope vs. header sender address
+
+ Questions were raised why the proposed mechanism is based on the
+ envelope sender address, and not on the sender address given in the
+ message header. Technically, both can be used. Actually, it makes
+ sense to use the envelope address.
+
+ In common, the header sender address identifies the author of the
+ content, while the envelope sender tells who caused the
+ transmission. The approach proposed in this memo is transmission
+ based, not content based. We can not authorize the author of a
+ message if we don't have contact with him, if the message does not
+ already contain a signature. In contrast, the sending MTA is linked
+ to an IP address which can be used for authentication. This
+ mechanism might not be very strong, but it is available and
+ sufficient to solve today's e-mail security problems.
+
+ Some people argued that it is the header address and not the sender
+ address, which is displayed in common mail readers (MUAs), and
+ where the receiver believes the mail comes from. That's true, but
+ it doesn't help. There are many cases where the header sender
+ differs from the envelope sender for good reasons (see below in the
+ consequences chapter for the discussion about relaying). Relaying,
+ mailing lists etc. require to replace the sender address used for
+ RMX. If this were the header address, the message header would have
+ to be modified. This is undesirable.
+
+3.3. Domain part vs. full sender address
+
+ Former versions of this draft were limited to the domain part of
+ the sender address. The first reason is that it is common and MX-
+ like, to lookup only the domain part of an e-mail address in DNS.
+ The second reason is, that it was left to the private business of
+ the domain administration to handle details of user verification.
+ The idea was that the domain administration takes care to verify
+ the left part of an e-mail address with an arbitrary method of
+ their individual taste. RMX was originally designed to ignore the
+ left part of the address and to expect the domain administration to
+
+
+
+Hadmut Danisch Experimental [Page 9]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ take over responsibility for enforcing their policy. If, e.g., a
+ spam message arrived and passed the RMX mechanism, it is known to
+ be authorized by the domain administration and they can be blamed,
+ no matter what is on the left side of the sender address - it's
+ their private problem what happens on the left side of the @. By
+ far the most of the comments to prior versions of this draft agreed
+ with that. A few comments asked for a finer granularity.
+
+ And indeed, there is no technical reason against a finer
+ granularity. All it takes is a mapping from a given envelope
+ sender address to a DNS name, and the RMX lookup for that
+ particular e-mail address could be done instead of a lookup for the
+ domain part only. However, to my knowledge, most domain
+ administrators would not like to provide an RMX entry for every
+ single e-mail address. In many cases, this would also overload DNS
+ servers.
+
+ It is to be discussed how to cover both views. One method could be
+ to query the full address, and if no RMX records were found to
+ query the domain part only. A different approach would be to query
+ the domain part only, and if it's RMX record contain a special
+ entry, then a new query for the full address is triggered. A third
+ way would be to always query the full address and to leave the
+ problem to the wildcard mechanism of DNS. This still has to be
+ discussed and will be described in future versions of this draft.
+
+
+
+
+
+
+
+
+
+
+
+4. Mapping of E-Mail addresses to DNS names
+
+ To perform the RMX query, a mapping is needed from E-Mail addresses
+ to DNS fully qualified domain names.
+
+ This chapter is under development and just a first approach.
+
+4.1. Domain part only
+
+ Mapping of the domain part is trivial, since the domain part of an
+ e-mail address itself is a valid DNS name and does not need
+ translation. It might be nevertheless desirable to distinguish the
+
+
+
+Hadmut Danisch Experimental [Page 10]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ RMX entries from other entries, depending of the encoding of the
+ records. If the RMX entries are encoded in TXT record types, they
+ might collide with other uses of TXT records. It might be
+ necessary to prepend the domain part with a special prefix, e.g.
+ _rmx. So the e-mail address some.user@example.com could be mapped
+ to example.com or _rmx.example.com.
+
+4.2. Full address
+
+ Mapping a full address is slightly more difficult. The @ sign must
+ be unambiguously translated, and therefore can not be simply
+ translated into a dot. The e-mail addresses some.user@example.com
+ and some@user.example.com must have different mappings. Therefore,
+ the @ sign could be translated into _rmx, implicitely assuming that
+ this is not an allowed domain name component of normal domain
+ names. Then the rightmost _rmx in the mapped DNS name always
+ corresponds to the @ sign. some.user@example.com would e translated
+ into some.user._rmx.example.com and can be covered by a wildcard
+ entry like *._rmx.example.com.
+
+ Character encoding and character sets are still to be discussed.
+
+4.3. Empty address
+
+ Unfortunately, SMTP allows empty envelope sender addresses to be
+ used for error messages. Empty sender addresses can therefore not
+ be prohibited. As observed, a significant amount of spam was sent
+ with such an empty sender address. To solve this problem, the host
+ name given in the HELO or EHLO command is taken to lookup the RMX
+ records instead. This makes sense, since such messages were
+ generated by the machine, not a human.
+
+
+
+
+5. Mandatory entry types and their syntax
+
+ The entry types described in this section MUST be supported by any
+ implementation of this draft.
+
+5.1. Overall structure
+
+ Similar to APL, an RMX record is just a concatenation of zero or
+ more RMX entries. The entries within one record form an ordered
+ rule base as commonly usual in packet filtes and firewall rulesets,
+ i. e. they are processed one ofter another until the first entry
+ matches. This entry determines the result of the query. Once a
+ matching entry is found, the RMX processing is finished.
+
+
+
+Hadmut Danisch Experimental [Page 11]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ For any domain name there should not exist more than a single RMX
+ record. Due to the structure of DNS, it is nevertheless possible to
+ have more than a single RMX record. Multiple RMX records are
+ treated as a single record consisting of the concatenation of all
+ records. While the entries in a record are ordered, the records are
+ not ordered and may be processed in arbitrary order. If the order
+ of the entries matters, it is the zone maintainer's responsibility
+ to keep those entries in a single record. For example, there are
+ negative entries, which exclude IP addresses from authorization.
+ It is important that these entries are processed before positive
+ entries giving permission to a wider address range. Since order is
+ guaranteed only within a record, corresponding negative and
+ positive entries must be put in the same record.
+
+ An RMX record may consist of one or more entries, where the entries
+ are separated by whitespace. An entry must not contain white space.
+ Each entry consists of an optional exclamation sign, a tag, a
+ colon, and the entry data:
+
+ [!] TAG : ENTRY-SPECIFIC-DATA
+
+ If the entry starts with an exclamation sign, the entry is negated.
+ See the entry type description below for details.
+
+ The TAG is the mnemonic type identifier or the decimal number of
+ the entry. The TAG is case-insensitive. It is immediately followed
+ by a colon.
+
+ The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
+ entry type. See description below.
+
+ Example:
+
+ danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
+ ipv4:1.2.3.0/24
+
+5.2. Unused
+
+ This is a primitive entry which just says that this sender address
+ will never be used as a sender address under any circumstances.
+ Example:
+
+ testdomain.danisch.de IN RMX unused:
+
+5.3. IPv4 and IPv6 address ranges
+
+ These entry types contain a bit sequence representing a CIDR
+ address part. If that bit sequence matches the given IP address,
+
+
+
+Hadmut Danisch Experimental [Page 12]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ authorization is granted or denied, depending on the negation flag.
+
+ The entry is prepended with the tag "IPv4" or "IPv6". The colon is
+ followed with an IPv4 or IPv6 address in standard notation,
+ optionally followed by a slash and a mask length. If the negation
+ flag is set, then the given address range is excluded. Examples:
+
+ danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0
+ IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16
+ IN RMX !ipv4:1.2.3.4
+
+ (Please note that it does not make much sense to use
+ RFC1918-Addresses in RMX records, this is just to give a syntax
+ example.)
+
+
+5.4. DNS Hostname
+
+ This entry type simply contains a regular DNS name, which is to be
+ resolved as a host name (fetch the A record or IPv6 equivalent). If
+ the given IP address matches the result, authorization is granted
+ or denied, depending on the negation flag. It is still to be
+ defined how to treat unresolvable entries.
+
+ The entry is prepended with the tag "host", followed by a colon and
+ the hostname. Examples:
+
+ danisch.de IN RMX host:relay.provider.de
+ IN RMX !host:badmachine.domain.de apl:relays.domain.de
+
+5.4.1. Road warriors and DynDNS entries
+
+ Several people argued against RMX that it would break their
+ existing installation which delivers e-mail from dynamically
+ assigned IP addresses, because their IP providers didn't assign a
+ static address, or because they are a road warrior, plugging their
+ notebook in any hotel room on the world.
+
+ RMX provides a simple solution. If such a machine has a dynamically
+ updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
+ the hostname type pointing to this dynamic DNS entry.
+
+ The cleaner solution would be to deliver mail the same way as it is
+ received: If downloaded by POP from a central relay with a static
+ address, where the MX points to, then it would be a good idea to
+ deliver e-mail the same way in reverse direction. Unfortunately,
+ plain POP does not support uploading yet.
+
+
+
+
+Hadmut Danisch Experimental [Page 13]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+5.5. APL Reference
+
+ This entry type simply contains a regular DNS name, which is to be
+ resolved as an APL record index (fetch the APL record). If the
+ given IP address positively matches the APL, authorization is
+ granted. Details of the semantic (espially when the negation bit is
+ set) are still to be defined. It is still to be defined how to
+ treat unresolvable entries.
+
+ The entry is prepended with the tag "host", followed by a colon and
+ the hostname. Example:
+
+ danisch.de IN RMX apl:relays.rackland.de
+
+5.6. Domain Member
+
+ In many cases it is desirable to cover all hosts of a given domain
+ with an RMX record without the need to duplicate the list of these
+ hosts. This entry type does it (thanks to Eric A. Hall for pointing
+ out this entry type). It contains a regular DNS name.
+
+ If this entry type is given, a reverse DNS query for the IP address
+ of the sending MTA is performed to find its official fully
+ qualified domain name. To prevent spoofing, this domain name is
+ accepted only if a subsequent address query to the given domain
+ name points to exactly the IP address of the sending MTA (the usual
+ procedure to verify PTR records).
+
+ The entry matches if the fully qualified domain name of the sending
+ MTA ends in the given domain. The negation flag works as usual.
+
+ The tag for this entry type is "domain". After the colon the domain
+ name is given, but might be empty, thus pointing to itself.
+ Example:
+
+ somedomain.org IN RMX domain:somedomain.org domain:provider.com
+
+ would authorize all machines which's hostname can be verified
+ through an PTR and A query, and which ends in "somedomain.org" or
+ "provider.com".
+
+ With such an entry, large companies with different networks can
+ easily be covered with just a single and simple RMX entry.
+ Obviously, it requires proper PTR records.
+
+ As a special shortcut, the DNS name may be empty. In this case the
+ domain name of the zone itself is taken. Thus, with a very simple
+ entry of the type
+
+
+
+Hadmut Danisch Experimental [Page 14]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ somecompany.com IN RMX domain:
+
+ a company could authorize all machines which's IP addresses map to
+ DNS names end in somecompany.com, which applies in the majority of
+ companies.
+
+
+
+
+5.7. Full Address Query
+
+ As described above, RMX records will in most cases apply to the
+ domain part of the sender address. In special cases it might be
+ desirable to query the RMX record for a particular address. An RMX
+ entry of the Full Address Query type may occur in a domain RMX
+ record only. It signals that the RMX record for the full address is
+ to be fetched and processed.
+
+ This entry type does not take arguments. The negation flag is not
+ supported. The tag is "full".
+
+ If such a full address query is to be performed, the mail address
+ must be mapped to a valid and non-ambiguos DNS name. This mapping
+ is still to be defined. It is not sufficient to simply replace the
+ @ with a dot, because of case sensitivity, character sets, etc. The
+ e-mail addresses
+
+ john.doe@example.org
+ John.Doe@example.org
+ john@doe.example.org
+
+ must all be mapped to different DNS entries. This entry type might
+ vanish in future versions of the draft, depending on the discussion
+ about whether to query the domain name part only or the full
+ address.
+
+5.8. DNS mapped authorization
+
+ As I learned from comments to prior versions of the draft and from
+ alternative proposals, many users wish to have a DNS mapped
+ authorization table, i. e. the client queries a DNS entry of the
+ form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
+ Since people wish to have this, RMX will now include such a mapping
+ entry. The entry has a parameter giving the DNS domain name where
+ to look at. If the parameter is empty, then the same domain is
+ taken as for the RMX lookup.
+
+ As this is currently under construction and discussion in an IETF
+
+
+
+Hadmut Danisch Experimental [Page 15]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ group, details will be published in future versions of this draft.
+
+5.9. RMX reference
+
+ This entry type has no parameters. It means that all those machines
+ are authorized, which are pointed to by an MX record.
+
+6. Optional and experimental entry types
+
+ The following subsections roughly describe further entry types
+ which might not be supported by all implementations and might not
+ be allowed in all legislations. These methods might vanish in
+ future versions of the draft and are just considerations about what
+ to include in RMX and what to not include. The main purpose of this
+ section is to start discussion about such entry types.
+
+ The disadvantage of the following methods is that they violate the
+ basic idea of RMX, i. e. to be simple, robust, easy to implement
+ and easy to administer. I personally do not believe that it is a
+ good idea or even feasible to implement cryptography for a world
+ wide e-mail transfer network. Keep in mind that cryptographic keys
+ can be copied. If only <0.1% of cryptographic keys were revealed,
+ this completely compromises and spoils RMX. Cryptography is simply
+ the wrong tool for the problem RMX is intended to solve. I
+ nevertheless like to discuss these methods.
+
+6.1. TLS fingerprint
+
+ The sender is considered to be authorized if the message was
+ transmitted through SMTP and TLS, and the sender used a certificate
+ matching the fingerprint given in the RMX record.
+
+6.2. TLS and LDAP
+
+ This means that the receiver should perform an LDAP query for the
+ sender address (through the LDAP SRV record or given in the RMX
+ record), fetch the X.509 certificate for the sender. The sender is
+ considered to be authorized when the message was transmitted
+ through SMTP and TLS using this certificate.
+
+6.3. PGP or S/MIME signature
+
+ It would be possible to accept a message only if it was signed with
+ PGP or S/MIME with a key which's fingerprint is given in the RMX
+ record or to be fetched from LDAP or any PGP database. This is
+ just for discussion, since it violates the idea of RMX to focus on
+ the transport, not on the content. It would also allow replay
+ attacks and not cover the envelope sender address or message
+
+
+
+Hadmut Danisch Experimental [Page 16]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ header.
+
+6.4. Transparent Challenge/Response
+
+ It would also be possible to implement a challenge-response
+ mechanism without modifying the syntax of SMTP. For example, the
+ receiving MTA could issue a challenge with it's very first greeting
+ message, the sending MTA could hide the response in the HELO
+ parameter and when the receiving MTA later learns the sender
+ envelope address, it could verify the response based on
+ informations in the RMX record.
+
+6.5. SASL Challenge/Response
+
+ Modern SMTP implementations already include a SASL mechanisms,
+ which easily allows to plugin new authentication mechanisms. While
+ common SASL mechanisms require to use a previously shared password,
+ a new mechanism could perform a challenge response authentication
+ as a SASL method.
+
+
+
+
+
+
+7. Encoding
+
+7.1. Alternative encoding as TXT records
+
+ The main objection against the prior versions of this draft was
+ that it requires a new RR entry type and upgrading all DNS servers.
+
+ Therefore and alternative encoding is proposed. Instead of using a
+ new RR type, the TXT record type is used to contain the RMX record.
+ The records would simply look as described in the entry type
+ chapters above, e.g.
+
+ _rmx.danisch.de. IN TXT "apl:relays.rackland.de"
+
+ To allow smooth introduction of RMX without the need to immediately
+ upgrade all DNS servers, all clients (which have to be newly
+ installed anyway) MUST support both the TXT and the RMX records. A
+ client has to perform an ANY or a TXT and a RMX query. Servers/zone
+ tables may currently use TXT entries but SHOULD use RMX entries in
+ future.
+
+7.2. RMX Records
+
+
+
+
+Hadmut Danisch Experimental [Page 17]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+7.2.1. Overall structure
+
+ Each entry starts with an octet containting the entry type and the
+ negation flag:
+
+ +---+---+---+---+---+---+---+---+------
+ | N | Entry Type Code | Parameters...
+ +---+---+---+---+---+---+---+---+------
+
+ N If this bit (MSB) is set, an IP address
+ matching this entry is not authorized,
+ but explicitely rejected. See entry
+ type descriptions for details.
+
+ Entry Type A 7bit number simply determining the entry
+ type.
+
+
+ Currently, entries do not have an explicit length field, the entry
+ length is determined implicitely by the entry type. Applications
+ are required to abort if an unknown entry type is found, instead of
+ skipping unknown entries.
+
+7.2.2. Record encoding
+
+ A RMX record is simply a concatenation of RMX entries.
+
+7.2.3. Encoding of IPv4 and IPv6 address ranges
+
+ After the entry type tag as described above, one octet follows
+ giving the length L of the bit sequence. Then a sequence of exactly
+ as many octets follows as needed to carry L bits of information (=
+ trunc((L+7)/8) ).
+
+ +---+---+---+---+---+---+---+---+
+ | N | Entry Type Code (1 or 2) |
+ +---+---+---+---+---+---+---+---+
+ | Length Field L |
+ +---+---+---+---+---+---+---+---+
+ | Bit Field |
+ / ((L+7)/8) Octets /
+ +---+---+---+---+---+---+---+---+
+
+
+7.2.4. Encoding of DNS
+
+ After the entry type tag immediately follows a DNS encoded and
+ compressed [3] domain name.
+
+
+
+Hadmut Danisch Experimental [Page 18]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ +---+---+---+---+---+---+---+---+
+ | N | Entry Type Code (3..5) |
+ +---+---+---+---+---+---+---+---+
+ | Length Field L |
+ +---+---+---+---+---+---+---+---+
+ | Encoded DNS |
+ / Name as described in RFC1035 /
+ +---+---+---+---+---+---+---+---+
+
+ In contrast to earlier versions of this draft, the DNS name cannot
+ be compressed, since this would cause decompression errors when a
+ DNS server is part of the query chain which does not know this
+ particular RR type.
+
+7.2.5. Encoding of unused and full query
+
+ These entries do not contain parameters and does not allow the
+ negation flag. So the encoding is quite simple:
+
+ +---+---+---+---+---+---+---+---+
+ | 0 | Entry Type Code (6 or 7)|
+ +---+---+---+---+---+---+---+---+
+
+
+
+7.2.6. Additional Records
+
+ In order to avoid the need of a second query to resolve the given
+ host name, a DNS server should enclose the A record for that domain
+ name in the additional section of the additional section of the DNS
+ reply, if the server happens to be authoritative.
+
+ In order to avoid the need of a second query to resolve the given
+ host name, a DNS server should enclose the APL record for that
+ domain name in the additional section of the additional section of
+ the DNS reply, if the server happens to be authoritative.
+
+
+
+8. Message Headers
+
+ An RMX query must be followed by any kind of action depending on
+ the RMX result. One action might be to reject the message. Another
+ action might be to add a header line to the message body, thus
+ allowing MUAs and delivery programs to filter or sort messages.
+
+ In future, the RMX result might be melted into the Received: header
+ line.
+
+
+
+Hadmut Danisch Experimental [Page 19]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ The details of such entries are to be discussed. As a proposal the
+ following form is suggested:
+
+ X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
+
+ where
+
+ RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
+ "TempFail", "BadData", "Trusted".
+
+ ADDRESS is the IP address of the sending machine
+
+ HOST is the name of the machine performing the RMX query.
+
+ DATE is the date of the query.
+
+ MECHANISM is the RMX method used to authorize the sender.
+
+
+
+9. SMTP error messages
+
+ If a message is rejected because of RMX records, an error message
+ should be issued which explains the details. It is to be discussed
+ whether new SMTP error codes are to be defined.
+
+
+10. Message relaying and forwarding
+
+10.1. Problem description
+
+ Message forwarding and relaying means that an MTA which received an
+ e-mail by SMTP does not deliver it locally, but resends the message
+ - usually unchanged except for an additional Received header line
+ and maybe the recipient's address rewritten - to the next SMTP MTA.
+ Message forwarding is an essential functionality of e-mail
+ transport services, for example:
+
+ - Message transport from outer MX relay to the intranet
+ - Message forwarding and Cc-ing by .forward or .procmail-alike
+ mechanisms
+ - Mailing list processing
+ - Message reception by mail relays with low MX priority,
+ usually provided by third parties as a stand-by service
+ in case of relay failure or maintenance
+ - "Forwarding" and "Bouncing" as a MUA functionality
+
+ In all these cases a message is sent by SMTP from a host which is
+
+
+
+Hadmut Danisch Experimental [Page 20]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ not covered by the original sender domain's RMX records. While the
+ RMX records would forbid accepting this message, it still must be
+ accepted. The following subsections explain how to cope with
+ relaying.
+
+10.2. Trusted relaying/forwarding
+
+ In some cases the receiving MTA trusts the sending MTA to not fake
+ messages and to already have checked the RMX records at message
+ reception. As a typical example, a company might have an outer mail
+ relay which receives messages from the Internet and checks the RMX
+ records. This relay then forwards the messages to the different
+ department's mail servers. It does not make sense for these
+ department mail servers to check the RMX record, since the RMX
+ records have already been checked and - since the message was
+ relayed by the outer relay - always would deny the message. In this
+ case there is a trust relationship between the department relays
+ and the outer relay. So RMX checking is turned off for trusted
+ relays. In this example, the department relays would not check
+ messages from the outer relay (but for intranet security, they
+ could still check RMX records of the other departments sub-domains
+ to avoid internal forgery between departments).
+
+ Another common example are the low-priority MX relays, which
+ receive and cache e-mails when the high-priority relays are down.
+ In this case, the high-priority relay would trust the low-priority
+ relay to have verified the sender authorization and would not
+ perform another RMX verification (which would obviously fail).
+
+ When a relay forwards a message to a trusting machine, the envelope
+ sender address should remain unchanged.
+
+10.3. Untrusted relaying/forwarding
+
+ If the receiving MTA does not trust the forwarding MTA, then there
+ is no chance to leave the sender envelope address unchanged. At a
+ first glance this might appear impracticable, but this is
+ absolutely necessary. If an untrusted MTA could claim to have
+ forwarded a message from a foreign sender address, it could have
+ forged the message as well. Spammers and forgers would just have to
+ act as such a relay.
+
+ Therefore, it is required that, when performing untrusted
+ forwarding, the envelope sender address has to be replaced by the
+ sender address of someone responsible for the relaying mechanism,
+ e.g. the owner of the mailing list or the mail address of the user
+ who's .forward caused the transmission. It is important to stress
+ that untrusted relaying/forwarding means taking over responsibility
+
+
+
+Hadmut Danisch Experimental [Page 21]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ for the message. It is the idea of RMX records to tie
+ responsibility to message transmission. Untrusted relaying without
+ replacing the sender address would mean to transmit without taking
+ responsibility.
+
+ The disadvantage is that the original sender address is lost.
+ Therefore, whenever a sender address replacement happens, the
+ Received-Line must contain the old address. Many of today's MTAs
+ already insert the envelope recipient address, but not the sender
+ address into the Received header line. It seems reasonable to
+ require every Received line to include both the sender and
+ recipient address of the incoming SMTP connection.
+
+
+11. Security Considerations
+
+11.1. Draft specific considerations
+
+11.1.1. Authentication strength
+
+ It is important to stress, that the suggested method does not
+ provide high level security and does not completely prevent forged
+ e-mails or spam under any circumstances. It is a robust, but not
+ highly reliable and completely secure security mechanism. Keep in
+ mind that it is based on DNS, and DNS is not secure today.
+ Authorization is based on the IP address. The very same machine
+ with the very same IP address could be authorized to send e-mail
+ with a given sender address and sending spam at the same time.
+ Maybe because several users are logged in. Or because several
+ customers use the same relay of the same ISP, where one customer
+ could use the sender address of a different customer. It is up to
+ the ISP to prevent this or not. Machines can still be hijacked.
+ Spammers are also domain owners. They can simply use their own
+ domain and authorize themselves. You will always find people on the
+ world who do not care about security and open their relays and RMX
+ records for others to abuse them. RMX is to be considered as a
+ very cheap and simple light weight mechanism, which can
+ nevertheless provide a significant improvement in mail security
+ against a certain class of attacks, until a successor of SMTP has
+ been defined and commonly accepted.
+
+11.1.2. Where Authentication and Authorization end
+
+ Previous versions of RMX records did not cover the local part of
+ the e-mail address, i.e. what's on the left side of the @ sign.
+ This is still to be discussed. Authentication and authorization are
+ limited to the sending MTA's IP address. The authentication is
+ limited to the TCP functionality, which is sufficient for light
+
+
+
+Hadmut Danisch Experimental [Page 22]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ weight authentication. The RMX records authorize the IP address of
+ the sending host only, not the particular sender of the message. So
+ if a machine is authorized to use sender addresses of more than a
+ single domain, the authentication scheme does not prevent that any
+ user on this machine can send with any of these domains. RMX is not
+ a substitute for the host security of the involved machines.
+
+ The proposed authentication scheme can be seen as a "half way
+ authentication": It does not track back an e-mail to the effective
+ sender. It tracks only half of the way, i. e. it tracks back to the
+ domain and it's DNS administrators who authorized that particular
+ sender IP address to use it for sending e-mail. How the party
+ responsible for that domain performs user authentication, whom it
+ grants access to, how it helds people responsible for abuse, is
+ completely left as the private business of those who are in charge
+ of that domain. So this draft does not interfere with the domain's
+ individual security policy or any legislation about such policies.
+ On the other hand, the proposed authentication scheme does not give
+ any statement about the nature and quality of the domain's security
+ policy. This is an essential feature of the proposal: E-mail
+ authentication must be deployed world wide, otherwise it won't do
+ the job. Any security scheme interfering with the local
+ legislations or the domain's security policy will not be accepted
+ and can't effectively deployed. Therefore, the security policy must
+ remain the domain's private business, no matter how lousy the
+ policy might be.
+
+ In order to achieve this and to make use of the only existing world
+ wide Internet directory scheme (DNS), the approach of this proposal
+ is to just ignore the local part of the sender address (i.e. what's
+ left of the @ part) and limit view to the domain part. After all,
+ that's what we do anyway when delivering to a given address with
+ SMTP.
+
+11.1.3. Vulnerability of DNS
+
+ DNS is an essential part of the proposed authentication scheme,
+ since it requires any directory service, and DNS is currently the
+ only one available. Unfortunately, DNS is vulnerable and can be
+ spoofed and poisoned. This flaw is commonly known and weakens many
+ network services, but for reasons beyond that draft DNS has not
+ been significantly improved yet. After the first version of this
+ draft, I received several comments who asked me not to use DNS
+ because of its lack of security. I took this into consideration,
+ but came to the conclusion that this is unfeasible: Any
+ authentication scheme linked to some kind of symbolic identity (in
+ this case the domain name) needs some kind of infrastructure and
+ trusted assignment. There are basically two ways to do it: Do it
+
+
+
+Hadmut Danisch Experimental [Page 23]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ yourself and trust nobody else, or let someone else do it. There
+ are methods to do it the former way, e.g. to give someone some kind
+ of authentication information after a first successful e-mail
+ exchange, e.g. some kind of cookie or special e-mail address. This
+ is certainly interesting and powerful, but it does not solve the
+ problem on a world wide scale and is far to complicated and error
+ prone for the average user, i. e. 99% of the users.
+
+ The latter method to let someone else do the symbolic name
+ assignment and create the authentication framework is well known.
+ It context of public key cryptography, this is called a Public Key
+ Infrastructure (PKI). On of the best known facts about PKIs is
+ that, until now, we don't have any covering a significant part of
+ the Internet. And we won't have any in near future. The complexity
+ is far too high, it is too expensive, and it involves cooperation
+ of every single user, which is simply unrealistic and extremely
+ error prone. So what do we have we can use? All we have is the DNS
+ and the Whois database. And we have countries who don't allow
+ cryptography. So the proposal was designed to use DNS without
+ cryptography. It does not avoid DNS because of its vulnerability,
+ it asks for a better DNS, but accepts the DNS as it is for the
+ moment. Currently there are two main threats caused by the DNS
+ weakness:
+
+ - A spammer/forger could spoof DNS in order to gain false
+ authorization to send fake e-mails.
+
+ - An attacker could spoof DNS in order to block delivery from
+ authorized machines, i. e. perform a Denial of Service attack.
+
+ The first one is rather unrealistic, because it would require an
+ average spammer to poison a significant part of the DNS servers of
+ its victims. A spammer sending messages to one million receipients
+ would need to poison at least 1-10% which is 10,000 to 100,000
+ receipient's DNS servers. This should be unfeasible in most cases.
+
+ In contrast, the second threat is a severe one. If an attacker
+ wanted to block messages from one company to another, he just needs
+ to poison the recipients DNS server with a wrong RMX record in
+ order to make the recipient's SMTP machine reject all messages. And
+ this is feasible since the attacker needs to poison only a single
+ DNS server. But does this make SMTP more vulnerable? No. Because
+ the attacker can already do even more without RMX. By poisoning the
+ sender's DNS server with wrong MX records, the attacker can also
+ block message delivery or even redirect the messages to the
+ attacker's machine, thus preventing any delivery error messages and
+ furthermore getting access to the messages.
+
+
+
+
+Hadmut Danisch Experimental [Page 24]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ As a consequence, e-mail delivery by SMTP requires a better DNS
+ anyway. The requirements are not significantly expanded by RMX.
+
+11.1.4. Sneaking RMX attack?
+
+ While writing a test implementation, a certain kind of attack came
+ into my mind. I'm still not sure, whether this attack is possible
+ on any DNS server, but I believe it should be mentioned:
+
+ Imagine an unauthorized sender is sending a forged mail (e.g.
+ spam). At connection time, before querying the RMX record, the
+ receiving MTA usually performs a PTR query for the IP address of
+ the sending MTA. If the sender has control over the authoritative
+ name server for that particular IP address, the sender could give a
+ normal PTR answer, but could append a wrong RMX, APL, or A record
+ in the additional section of the query. A subsequent RMX query
+ could receive wrong DNS data if the DNS server used by the
+ receiving MTA accepted those forged records.
+
+11.1.5. Open SMTP relays
+
+ Open SMTP relays (i.e. machines who accept any e-mail message from
+ anyone and deliver to the world) abused by spammers are a one of
+ the main problems of spam defense and sender backtracking. In most
+ cases this problem just vanishes because foreign open relay
+ machines will not be covered by the RMX records of the forged
+ sender address. But there are two special cases:
+
+ If the spammer knows about a domain which authorizes this
+ particular machine, that domain can be used for forgery. But in
+ this case, the IP address of the relay machine and the RMX records
+ of the domain track back to the persons responsible. Both can be
+ demanded to fix the relay or remove the RMX record for this
+ machine. An open relay is a security flaw like leaving the machine
+ open for everybody to login and send random mails from inside. Once
+ the administrative persons refuse to solve the problem, they can be
+ identified as spammers and held responsible.
+
+ The second special case is when a domain authorizes all IP
+ addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
+ this case, open relays don't make things worse. It's up to the
+ recipient's MTA to reject mails from domains with loose security
+ policies.
+
+11.1.6. Unforged Spam
+
+ This proposal does not prevent spam (which is, by the way, not yet
+ exactly defined), it prevents forgery. Since spam is against law
+
+
+
+Hadmut Danisch Experimental [Page 25]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ and violates the recipients rights, spam depends on untracability
+ of the sender. In practice the sender forges the sender address
+ (other cases see below). This proposal is designed to detect such
+ forgeries.
+
+ However, the RMX approach is rendered ineffective, if the sender
+ doesn't forge. If the sender uses just a normal address of it's own
+ domain, this is just a plain, normal e-mail, which needs to be let
+ through. Since it is up to the human's taste whether this is spam
+ or not, there's no technical way to reliably identify this as spam.
+ But since the sender domain is known, this domain can be
+ blacklisted or legal steps can be gone into.
+
+11.1.7. Reliability of Whois Entries
+
+ Once the RMX infrastructure gets deployed, what's the security
+ gain? It allows to determine the domain which's DNS zone
+ authorized the sending machine. What's that good for? There are
+ some immediate uses of the domain name, e.g. in black- and
+ whitelisting. But in most cases this is just the starting point of
+ further investigations, either performed automatically before
+ message acceptance, or manually after spam has been received and
+ complainted about.
+
+ The next step after determining the domain is determining the
+ people responsible for this domain. This can sometimes be achieved
+ by querying the Whois databases. Unfortunately, many whois entries
+ are useless because they are incomplete, wrong, obsolete, or in
+ uncommon languages. Furthermore, there are several formats of
+ address informations which make it difficult to automatically
+ extract the address. Sometimes the whois entry identifies the
+ provider and not the owner of the domain. Whois servers are not
+ built for high availability and sometimes unreachable.
+
+ Therefore, a mandatory standard is required about the contents and
+ the format of whois entries, and the availability of the servers.
+ After receiving the MAIL FROM SMTP command with the sender envelope
+ address, the receiving MTA could check the RMX record and Whois
+ entry. If it doesn't point to a real human, the message could be
+ rejected and an error message like "Ask your provider to fix your
+ Whois entry" could be issued. Obviously, domain providers must be
+ held responsible for wrong entries. It might still be acceptable to
+ allow anonymous domains, i. e. domains which don't point to a
+ responsible human. But it is the receivers choice to accept e-mails
+ from such domains or not.
+
+11.1.8. Hazards for Freedom of Speech
+
+
+
+
+Hadmut Danisch Experimental [Page 26]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ Currently, some governments try to enforce limitations of internet
+ traffic in order to cut unwanted content providers from the
+ network. Some of these governments try to hide a whole country
+ behind firewalls, others try to force Internet providers to poison
+ DNS servers with wrong A records for web servers, e.g. one county
+ administration in Germany tries to do so. If message reception
+ depends on DNS entries, the same governments will try to block not
+ only HTTP, but SMTP also.
+
+ However, since most MTAs already reject messages from unresolvable
+ domain names this is not a new threat.
+
+11.2. General Considerations about spam defense
+
+ After discussing security requirements of the proposal, now the
+ security advantages of the RMX approach over content based filters
+ will be explained. Basically, there are three kinds of content
+ filters:
+
+ - Those who upload the message or some digest to an external
+ third party and ask "Is this spam"?
+
+ - Those who download a set of patterns and rules from a third
+ party and apply this set to incoming messages in order to
+ determine whether it is spam.
+
+ - Those who are independent and don't contact any third party,
+ but try to learn themselves what is spam and what isn't.
+
+
+ The message filters provided by some e-mail service providers are
+ usually not a kind of their own, but a combination of the first two
+ kinds.
+
+11.2.1. Action vs. reaction
+
+ Content filters suffer from a fundamental design problem: They are
+ late. They need to see some content of the same kind before in
+ order to learn and to block further distribution.
+
+ This works for viruses and worms, which redistribute. This doesn't
+ work for spam, since spam is usually not redistributed after the
+ first delivery. When the filters have learned or downloaded new
+ pattern sets, it's too late.
+
+ This proposal does not have this problem.
+
+11.2.2. Content based Denial of Service attacks
+
+
+
+Hadmut Danisch Experimental [Page 27]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ All three kinds of content filters, but especially the second and
+ the third kind are vulnerable to content based Denial of Service
+ attacks.
+
+ If some kind of third party (e.g. non-democratic government,
+ intellectual property warriors, religious groups, military, secret
+ services, patriots, public relation agents, etc.) wants certain
+ contents not to be distributed, they could either poison the
+ pattern/rule databases or feed wrong sets to particular receivers.
+
+ Such pattern/rule sets are the perfect tool for censoring e-mail
+ traffic and denial of service attacks by governments and other
+ parties, and a similar threat are virus filters. E. g. the content
+ industry could demand to teach all virus and spam filters to delete
+ all e-mails containing the URL of an MP3 web server outside the
+ legislations. Software manufacturers could try to block all e-mails
+ containing software license keys, thus trying to make unallowed
+ distribution more difficult. Governments could try to block
+ distribution of unwanted informations.
+
+ This proposal does not have this problem.
+
+
+12. Privacy Considerations
+
+ (It was proposed on the 56th IETF meeting to have a privacy section
+ in drafts and RFCs.)
+
+12.1. Draft specific considerations
+
+12.1.1. No content leaking
+
+ Since the RMX approach doesn't touch the contents of a message in
+ any way, there is obviously no way of leaking out any information
+ about the content of the message. RMX is based solely on the
+ envelope recipient address. However, methods to fix problems not
+ covered by RMX might allow content leaking, e.g. if the acceptance
+ of a message with an empty sender address requires the reference to
+ the message id of an e-mail recently sent, this allows an attacker
+ to verify whether a certain message was delivered from there.
+
+12.1.2. Message reception and sender domain
+
+ Message delivery triggers RMX and APL requests by the recipient.
+ Thus, the admin of the DNS server or an eavesdropper could learn
+ that the given machine has just received a message with a sender
+ from this address, even if the SMTP traffic itself had been
+ encrypted.
+
+
+
+Hadmut Danisch Experimental [Page 28]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ However, most of today's MTAs do query the MX and A records of the
+ domain after the MAIL FROM command, so this is not a real new
+ threat.
+
+12.1.3. Network structure
+
+ Since RMX and its associated APL records provide a complete list of
+ all IP addresses of hosts authorized to send messages from this
+ address, they do reveal informations about the network structure
+ and maybe the lifestyle of the domain owner, since a growing number
+ of domains are owned by single persons or families. E.g. the RMX
+ records could reveal where someone has his job or spends his time
+ at weekends.
+
+ If such informations are to be kept secret, it is the user's job to
+ not sent e-mails from there and to relay them from non-compromising
+ IP addresses.
+
+12.1.4. Owner information distribution
+
+ As described above, RMX depends partly on the reliability of the
+ whois database entries. It does not make anonymous domains
+ impossible, but it requires to keep the database entries "true", i.
+ e. if a whois entry does not contain informations about the
+ responsible person, this must be unambigously labeled as anonymous.
+ It must not contain fake names and addresses to pretend a non-
+ existing person. However, since most Internet users on the world
+ feel extremely annoyed by spam, they will urge their MTA admin to
+ reject messages from anonymous domains. The domain owner will have
+ the choice to either remain anonymous but be not able to send e-
+ mail to everyone in the world, or to be able but to reveal his
+ identity to everyone on the world.
+
+ It would be possible to provide whois-like services only to
+ recipients of recent messages, but this would make things too
+ complicated to be commonly adopted.
+
+12.2. General Considerations about spam defense
+
+12.2.1. Content leaking of content filters
+
+ As described above in the Security chapter, there are spam filters
+ which inherently allow leakage of the message body. Those filters
+ upload either the message body, or in most cases just some kind of
+ checksum to a third party, which replies whether this is to be seen
+ as spam or not. The idea is to keep a databases of all digests of
+ all messages. If a message is sent more often than some threshold,
+ it is to be considered as a mass mail and therefore tagged as spam.
+
+
+
+Hadmut Danisch Experimental [Page 29]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ While the digest itself does not reveal the content of the message,
+ it perfectly reveals where a particular message has been delivered
+ to. If a government finds just a single unwanted message, if a
+ software manufacturer finds a single message with a stolen product
+ license key, if someone finds a message with unpatriotic content,
+ it takes just a single database lookup to get a list of all people
+ who received this particular message. Content filters with digest
+ upload are the perfect "Big Brother".
+
+12.2.2. Black- and Whitelists
+
+ Some proposals against spam are based on a central database of
+ white- or blacklisted IP addresses, Sender names, Message IDs or
+ whatever. Again, there is a central database which learns who has
+ received which e-mail or from which sender with every query. This
+ allows tracking relations between persons, which is also a breach
+ of privacy.
+
+
+
+13. Deployment Considerations
+
+13.1. Compatibility
+
+13.1.1. Compatibility with old mail receivers
+
+ Since the suggested extension doesn't change the SMTP protocol at
+ all, it is fully compatible with old mail receivers. They simply
+ don't ask for the RMX records and don't perform the check.
+
+13.1.2. Compatibility with old mail senders
+
+ Since the SMTP protocol is unchanged and the SMTP sender is not
+ involved in the check, the method is fully compatible with old mail
+ senders.
+
+13.1.3. Compatibility with old DNS clients
+
+ Since the RMX is a new RR, the existing DNS protocol and zone
+ informations remain completely untouched.
+
+ If RMX is provided as a TXT record instead, it must be ensured that
+ no other software is misinterpreting this entry.
+
+13.1.4. Compatibility with old DNS servers
+
+ Full compatibility: If the server does not support RMX records, RMX
+ in TXT records can be used.
+
+
+
+Hadmut Danisch Experimental [Page 30]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+13.2. Enforcement policy
+
+ Obviously, for reasons of backward compatibility and smooth
+ introduction of this scheme, RMX records can't be required
+ immediately. Domains without RMX records must temporarily be
+ treated the same way as they are treated right now, i.e. e-mail
+ must be accepted from anywhere. But once the scheme becomes
+ sufficiently widespread, mail relays can start to refuse e-mails
+ with sender addresses from domains without RMX records, thus
+ forcing the owner of the domain to include a statement of
+ authorization into the domain's zone table. Domain owners will
+ still be free to have an RMX record with a network and mask
+ 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
+ On the other hand, mail receivers will be free to refuse mails from
+ domains without RMX records or RMX records which are too loose.
+ Advanced MTAs might have a configuration option to set the maximum
+ number of IP addresses authorized to use a domain. E-mails from a
+ domain, which's RMX records exceed this limit, would be rejected.
+ For example, a relay could reject e-mails from domains which
+ authorize more than 8 IP addresses. That allows to accept e-mails
+ only from domains with a reasonable security policy.
+
+
+
+14. General considerations about fighting spam
+
+ Is there a concise technical solution against spam? Yes.
+
+ Will it be deployed? Certainly not.
+
+ Why not? Because of the strong non-technical interests of several
+ parties against a solution to the problem, as described below.
+ Since these are non-technical reasons, they might be beyond the
+ scope of such a draft. But since they are the main problems that
+ prevent fighting spam, it is unavoidable to address them. This
+ chapter exists temporarily only and should support the discussion
+ of solutions. It is not supposed to be included in a later RFC.
+
+14.1. The economical problem
+
+ As has been recently illustrated in the initial session of the
+ IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
+ sending spam is a business with significant revenues.
+
+ But a much bigger business is selling Anti-Spam software. This is a
+ billion dollar market, and it is rapidly growing. Any simple and
+ effective solution against spam would defeat revenues and drive
+ several companies into bankrupt, would make consultants jobless.
+
+
+
+Hadmut Danisch Experimental [Page 31]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ Therefore, spam is essential for the Anti-Spam business. If there
+ is no spam, then no Anti-Spam software can be sold, similar to the
+ Anti-Virus business. There are extremely strong efforts to keep
+ this market growing. Viruses, Worms, and now spam are just perfect
+ to keep this market alive: It is not sufficient to just buy a
+ software. Databases need to be updated continuously, thus making
+ the cash flow continuously. Have a single, simple, and permanent
+ solution to the problem and - boom - this billion dollar market is
+ dead.
+
+ That's one of the reasons why people are expected to live with
+ spam. They have to live with it to make them buy Anti-Spam
+ software. Content filters are perfect products to keep this market
+ alive.
+
+14.2. The POP problem
+
+ Another problem is the history of mail delivery. Once upon a time,
+ there used to be very few SMTP relays which handled the e-mail
+ traffic of all the world, and everybody was happy with that. Then
+ odd things like Personal Computers, which are sometimes switched
+ off, portable computers, dynamicly assigned IP addresses, IP access
+ from hotel rooms, etc. was invented, and people became unhappy,
+ because SMTP does not support delivery to such machines. To make
+ them happy again, the Post Office Protocol[4] was invented, which
+ turned the last part of message delivery from SMTP's push style
+ into a pull style, thus making virtually every computer on the
+ world with any random IP address a potential receiver of mails for
+ random domains. Unfortunately, only receiving e-mail was covered,
+ but sending e-mail was left to SMTP.
+
+ The result is that today we have only very few SMTP relays pointed
+ to by MX records, but an extreme number of hosts sending e-mail
+ with SMTP from any IP address with sender addresses from any
+ domain. Mail delivery has become very asymmetric. Insecurity,
+ especially forgeability, has become an essential part of mail
+ transport.
+
+ That problem could easily be fixed: Use protocols which allow
+ uploading of messages to be delivered. If a host doesn't receive
+ messages by SMTP, it shouldn't deliver by SMTP. Mail delivery
+ should go the same way back that incoming mail went in. This is
+ not a limitation to those people on the road who plug their
+ portable computer in any hotel room's phone plug and use any
+ provider. If there is a POP server granting download access from
+ anywhere, then the same server should be ready to accept uploading
+ of outgoing messages.
+
+
+
+
+Hadmut Danisch Experimental [Page 32]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ But as I saw from the comments on the first version of this draft,
+ people religiously insist on sending e-mail with their domain from
+ any computer with any IP address in the world, e.g. when visiting a
+ friend using her computer. It appears to be impossible to convince
+ people that stopping mail forgery requires every one of them to
+ give up forging.
+
+14.3. The network structure problem
+
+ A subsequent problem is that many organisations failed to implement
+ a proper mail delivery structure and heavily based their network on
+ this asymmetry. I received harsh comments from Universities who
+ were unable to give their network a good structure. While they do
+ have a central mail relay for incoming mail to the universities
+ domain, they developed a structure where every member of the
+ University randomly sends e-mails with that University's domain as
+ a sender address from home or everywhere in the world with any
+ dynamically assigned IP address from any provider. So this domain
+ is to be used from every possible IP address on earth, and they are
+ unable to operate any authentication scheme. Furthermore, they were
+ unable to understand that such a policy heavily supports spam and
+ that they have to expect that people don't accept such e-mails
+ anymore once they become blacklisted.
+
+ As long as organisations insist on having such policies, spammers
+ will have a perfect playground.
+
+14.4. The mentality problem
+
+ Another problem is the mentality of many internet users of certain
+ countries. I received harsh comments from people who strongly
+ insisted on the freedom to send any e-mail with any sender address
+ from anywhere, and who heavily refused any kind of authentication
+ step or any limitation, because they claimed that this would
+ infringe their constitutional "Freedom of speech". They are
+ undeviatingly convinced that "Freedom of speech" guarantees their
+ right to talk to everybody with any sender address, and that is has
+ to be kept the recipient's own problem to sort out what he doesn't
+ want to read - on the recipient's expense.
+
+ It requires a clear statement that the constitutional "Freedom of
+ Speech" does not cover molesting people with unsolicited e-mail
+ with forged sender address.
+
+14.5. The identity problem
+
+ How does one fight against mail forgery? With authentication. What
+ is authentication? In simple words: Making sure that the sender's
+
+
+
+Hadmut Danisch Experimental [Page 33]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+ real identity meets the recipients idea of who is the sender, based
+ on the sender address which came with the message.
+
+ What is identity? It is the main problem. Several countries have
+ different ideas of "identity", which turn out to be somehow
+ incompatible. In some countries people have identity cards and
+ never change their name and birthday. Identities are created by
+ human birth, not by identity changes. Other countries do not have
+ such a tight idea about identity. People's temporary identity is
+ based on nothing more than a driving license and a social security
+ number. With this background, it is virtually impossible to create
+ a trustworthy PKI covering all Internet users. I learned that it is
+ extremely difficult to convince some people to give up random e-
+ mail sending.
+
+14.6. The multi-legislation problem
+
+ Many proposals about fighting spam are feasible under certain
+ legislations only, and are inacceptable under some of the
+ legislations. But a world wide applicable method is required.
+ That's why the approach to ask everone on the world to sign
+ messages with cryptographic keys is not feasible.
+
+
+Implementation and further Information
+
+ Further informations and a test implementation are available at
+
+ http://www.danisch.de/work/security/antispam.html
+ http://www.danisch.de/software/rmx/
+
+
+ Additional informations and a technology overview are also
+ available at
+
+ http://www.mikerubel.org/computers/rmx_records/
+
+
+References
+
+
+
+1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
+ els," RFC 2119 (March 1997).
+
+2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
+
+
+
+
+
+Hadmut Danisch Experimental [Page 34]
+
+INTERNET-DRAFT DNS RMX RR Oct 2003
+
+
+3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
+ RFC 1035 (November 1987).
+
+4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
+ (May 1996).
+
+
+Draft History
+
+ 00 Dec 2002
+ 01 Apr 2003
+ 02 Jun 2003
+ 03 Oct 2003
+
+Author's Address
+
+ Hadmut Danisch
+
+ Tennesseeallee 58
+ 76149 Karlsruhe
+ Germany
+
+ Phone: ++49-721-843004 or ++49-351-4850477
+ E-Mail: rfc@danisch.de
+
+Comments
+
+ Please send comments to rfc@danisch.de.
+
+Expiry
+
+ This drafts expires on Apr 1, 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hadmut Danisch Experimental [Page 35]
+
diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt
new file mode 100644
index 0000000..7b5e8cc
--- /dev/null
+++ b/doc/draft/draft-dnsext-opcode-discover-02.txt
@@ -0,0 +1,241 @@
+
+IETF DNSEXT WG Bill Manning
+draft-dnsext-opcode-discover-02.txt ep.net
+ Paul Vixie
+ ISC
+ 13 Oct 2003
+
+
+ The DISCOVER opcode
+
+This document is an Internet-Draft and is subject to all provisions of
+Section 10 of RFC2026.
+
+Comments may be submitted to the group mailing list at "mdns@zocalo.net"
+or the authors.
+
+Distribution of this memo is unlimited.
+
+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.
+
+The capitalized keywords "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
+
+0. Abstract:
+
+ The QUERY opcode in the DNS is designed for unicast. With the
+ development of multicast capabilities in the DNS, it is desireable
+ to have a more robust opcode for server interactions since a single
+ request may generate replies from multiple responders. So DISCOVER
+ is defined to deal with replies from multiple responders.
+
+ As such, this document extends the core DNS specifications to allow
+ clients to have a method for coping with replies from multiple
+ responders. Use of this new opcode may facilitate DNS operations in
+ modern networking topologies. A prototype of the DISCOVER opcode
+ was developed during the TBDS project (1999-2000), funded under DARPA
+ grant F30602-99-1-0523.
+
+1. Introduction:
+
+ This document describes an experimental extension to the DNS to receive
+ multiple responses which is the likely result when using DNS that has
+ enabled multicast queries. This approach was developed as part of the
+ TBDS research project, funded under DARPA grant F30602-99-1-0523. The
+ full processing rules used by TBDS are documented here for possible
+ incorporation in a future revision of the DNS specification."
+
+2. Method:
+
+ DISCOVER works like QUERY except:
+
+ 1. it can be sent to a broadcast or multicast destination. QUERY
+ isn't defined for non-unicast, and arguably shouldn't be.
+
+ 2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
+ tuples. TBDS tried to augment this structure as follows:
+ <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
+ TBDS, it is cleaner to place the SRV question in a separate pass.
+
+ 3. if QDCOUNT equals 0 then only servers willing to do recursion should
+ answer. Other servers must silently discard the DISCOVER request.
+
+ 4. if QDCOUNT is not equal to 0 then only servers who are authoritative
+ for the zones named by some QNAME should answer.
+
+ 5. responses may echo the request's Question section or leave it blank,
+ just like QUERY.
+
+ 6. responses have standard Answer, Authority, and Additional sections.
+ e.g. the response is the same as that to a QUERY. It is desireable
+ that zero content answers not be sent to avoid badly formed or
+ unfulfilled requests. Responses should be sent to the unicast
+ address of the requester and the source address should reflect
+ the unicast address of the responder.
+
+ Example usage for gethostby{name,addr}-style requestors:
+
+ Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
+ ip6.arpa domain.
+
+ DISCOVER whether anyone in-scope is authoritative for this zone.
+
+ If so, query these authoritative servers for local
+ in-addr/ip6 names.
+
+ If not, DISCOVER whether there are recursive servers available.
+
+ If so, query these recursive servers for local
+ in-addr/ip6 names.
+
+ So, a node will issue a multicast request with the DISCOVER opcode at
+ some particular multicast scope. Then determine, from the replies,
+ whether there are any DNS servers which are authoritative (or support
+ recursion) for the zone. Replies to DISCOVER requests MUST set the
+ Recursion Available (RA) flag in the DNS message header.
+
+ It is important to recognize that a requester must be prepared to
+ receive multiple replies from multiple responders. We expect that
+ there will be a single response per responder.
+
+ Once one learns a host's FQDN by the above means, repeat the process
+ for discovering the closest enclosing authoritative server of such
+ local name.
+
+ Cache all NS and A data learned in this process, respecting TTL's.
+
+ TBDS usage for SRV requestors:
+
+ Do the gethostbyaddr() and gethostbyname() on one's own link-local
+ address, using the above process.
+
+ Assume that the closest enclosing zone for which an authority server
+ answers an in-scope DISCOVER packet is "this host's parent domain".
+
+ Compute the SRV name as _service._transport.*.parentdomain.
+
+ This is a change to the definition as defined in RFC 1034.
+ A wildcard label ("*") in the QNAME used in a DNS message with
+ opcode DISCOVER SHOULD be evaluated with special rules. The
+ wildcard matches any label for which the DNS server data is
+ authoritative. For example 'x.*.example.com.' would match
+ 'x.y.example.com.' and 'x.yy.example.com.' provided that the
+ server was authoritative for 'example.com.' In this particular
+ case, we suggest the follwing considerations be made:
+
+ getservbyname() can be satisfied by issuing a request with
+ this computed SRV name. This structure can be
+ populated by values returned from a request as follows:
+
+ s_name The name of the service, "_service" without the
+ preceding underscore.
+ s_aliases The names returned in the SRV RRs in replies
+ to the query.
+ s_port The port number in the SRV RRs replies to the
+ query. If these port numbers disagree - one
+ of the port numbers is chosen, and only those
+ names which correspond are returned.
+ s_proto The transport protocol from named by the
+ "_transport" label, without the preceding
+ underscore.
+
+ Send SRV query for this name to discovered local authoritative servers.
+
+ Usage for disconnected networks with no authoritative servers:
+
+ Hosts should run a "stub server" which acts as though its FQDN is a
+ zone name. Computed SOA gives the host's FQDN as MNAME, "." as the
+ ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
+ and the other timers. Compute NS as the host's FQDN. Compute the
+ glue as the host's link-local address. Or Hosts may run a
+ "DNS stub server" which acts as though its FQDN is a zone name. The
+ rules governing the behavior of this stub server are given elsewhere
+ [1] [2].
+
+ Such stub servers should answer DISCOVER packets for its zone, and
+ will be found by the iterative "discover closest enclosing authority
+ server" by DISCOVER clients, either in the gethostbyname() or SRV
+ cases described above. Note that stub servers only answer with
+ zone names which exactly match QNAME's, not with zone names which
+ are owned by QNAME's.
+
+ The main deviation from the DNS[3][4] model is that a host (like, say, a
+ printer offering LPD services) has a DNS server which answers authoritatively
+ for something which hasn't been delegated to it. However, the only way that
+ such DNS servers can be discovered is with a new opcode, DISCOVER, which
+ is explicitly defined to discover undelegated zones for tightly scoped
+ purposes. Therefore this isn't officially a violation of DNS's coherency
+ principles. In some cases a responder to DISCOVER may not be traditional
+ DNS software, it could be special purpose software.
+
+3. IANA Considerations
+
+ As a new opcode, the IANA will need to assign a numeric value
+ for the memnonic. The last OPCODE assigned was "5", for UPDATE.
+ Test implementations have used OPCODE "6".
+
+4. Security Considerations
+
+ No new security considerations are known to be introduced with any new
+ opcode, however using multicast for service discovery has the potential
+ for denial of service, primarly from flooding attacks. It may also be
+ possible to enable deliberate misconfiguration of clients simply by
+ running a malicious DNS resolver that claims to be authoritative for
+ things that it is not. One possible way to mitigate this effect is by
+ use of credentials, such as CERT resource records within an RR set.
+ The TBDS project took this approach.
+
+5. Attribution:
+
+ This material was generated in discussions on the mdns mailing list
+hosted by Zocalo in March 2000. Updated by discussion in September/October
+2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
+Erik Guttman, Bill Manning and Paul Vixie were active contributors.
+
+6. Author's Address
+
+ Bill Manning
+ PO 12317
+ Marina del Rey, CA. 90295
+ +1.310.322.8102
+ bmanning@karoshi.com
+
+ Paul Vixie
+ Internet Software Consortium
+ 950 Charter Street
+ Redwood City, CA 94063
+ +1 650 779 7001
+ <vixie@isc.org>
+
+7. References
+
+Informational References:
+
+[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
+ draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
+
+[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
+ draft-manning-dnsext-mdns-00.txt, August 2000. Expired.
+
+Normative References:
+[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
+ RFC 1034, November 1987.
+[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
+ RFC 1035, November 1987
+
+ ----------------------------EOL-----------------------
+
diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt
new file mode 100644
index 0000000..224e7ad1
--- /dev/null
+++ b/doc/draft/draft-durand-dnsop-dynreverse-00.txt
@@ -0,0 +1,240 @@
+Internet Engineering Task Force Alain Durand
+INTERNET-DRAFT SUN Microsystems
+Feb 21, 2003
+Expires Aug 2, 2003
+
+
+
+ Dynamic reverse DNS for IPv6
+ <draft-durand-dnsop-dynreverse-00.txt>
+
+
+
+Status of this memo
+
+
+ This memo provides information to the Internet community. It does
+ not specify an Internet standard of any kind. This memo is in full
+ conformance with all provisions of Section 10 of RFC2026 [RFC2026].
+
+ 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.
+
+
+
+Abstract
+
+ This document describes a method to dynamically generate PTR records
+ and corresponding A or AAAA records when the reverse path DNS tree is
+ not populated.
+
+ A special domain dynrev.arpa. is reserved for that purpose.
+
+
+1. Introduction
+
+ In IPv4, the reverse path tree of the DNS under in-addr.arpa.
+ although not perfectly maintained, is still mostly usable and its
+ existence is important for a number of applications that relies on
+ its existence and decent status. Some applications performs some
+ (very) weak security checks based on it. Mail relays relies on it for
+ some anti-spams checks an some FTP server will not let you in unless
+ your IP address resolve properly with a PTR record.
+
+ IPv6 addresses being much longer (and cumbersome) than IPv4
+ addresses, it is to fear that the reverse path tree under ip6.arpa.
+ would not be as well maintained. Also, tools like 6to4, Isatap and
+ others have made creative use of the 128 bits of an IPv6 address to
+ automatically embed an IPv4 address to enable seamless connection to
+ the IPv6 Internet. However, no provision has been made to make sure
+ the reverse path tree gets automatically updated as well for those
+ new IPv6 addresses. One step furter, RFC3041 describes a mechanism
+ to basically use random bits in the bottom part of an IPv6 address to
+ preserver anonymity. If those addresses are to resolve in the reverse
+ path tree, it obviously has to be with anonymous data as well.
+ Another point to note is that home customer ISPs in IPv4 have a
+ current practice to pre-populate the reverse path tree with names
+ automatically derived from the IP addresses. This practice is no
+ longer possible in IPv6, where IP address allocation is not dense as
+ it is the case in IPv4. The mere size of typical customer allocation
+ (2^48 according to the recommendation of RFC3177) makes it
+ impossible.
+
+ Applications that check the existence of PTR records usually follow
+ this by checking if the name pointed by the PTR resolve in a A (or
+ AAAA for IPv6) that match the original IP address. Thus the forward
+ path tree must also include the corresponding data.
+
+ One simple approach of this problem is to simply declare the usage of
+ the reverse path DNS as described above obsolete. The author believe
+ this is too strong an approach for now.
+
+ Similarly, a completely different approach would be to deprecate the
+ usage of DNS for the reverse tree altogether and replace it by
+ something inspired from ICMP name-info messages. The author believes
+ that this approached is an important departure from the current
+ practise and thus not very realistic. Also, there are some concerns
+ about the the security implications of this method as any node could
+ easily impersonate any name. This approach would fundamentally change
+ the underlying assumption of "I trust what has been put in the DNS by
+ the local administrators" to "I trust what has been configured on
+ each machine I query directly".
+
+
+
+2. Dynamic record generation
+
+ If static pre-population of the tree is not possible anymore and data
+ still need to be returned to applications using getnameinfo(), the
+ alternative is dynamic record generation. This can be done is two
+ places: in the DNS servers responsible for the allocated space (/64
+ or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the
+ sub resolver library or the recursive DNS server).
+
+ 2.1. On the resolver side.
+
+ The resolver, either in the recursive DNS server or in the stub
+ library could theoretically generate this data.
+
+ In case DNSsec is in place, the recursive DNS server would have to
+ pretend these records are authentic.
+
+ If the synthesis is done in the stub-resolver library, no record
+ needs to be actually generated, only the right information needs to
+ be passed to getnameinfo() and getaddrinfo(). If the synthesis is
+ done in the recursive DNS server, no modification is required to
+ existing stub resolvers.
+
+
+2.2. On the server side.
+
+ PTR records could be generated automatically by the server
+ responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
+ prefixes or basically anything in between) when static data is not
+ available.
+
+ There could be impact on DNSsec as the zone or some parts of the zone
+ may need to be resigned each time a DNS query is made for an
+ unpopulated address. This can be seen as a DOS attack on a DNSsec
+ zone, so server side synthesis is not recommended if DNSsec is
+ deployed.
+
+
+
+3. Synthesis
+
+ The algorithm is simple: Do the normal queries. If the query returns
+ No such domain, replace this answer by the synthetized one if
+ possible.
+
+3.1. PTR synthesis
+
+ The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
+ where [X] is any valid DNS name.
+
+ The fact that the synthetized PTR points to the dynrev.arpa. domain
+ is an indication to the applications that this record has been
+ dynamically generated.
+
+
+3.2. A synthesis
+
+ If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
+ record for the string [X].dynrev.arpa. which value is d.c.b.a. with
+ a,b,c & d being integer [0..255]
+
+
+3.3. AAAA synthesis
+
+ If [X] is in the form
+ a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
+ addr.arpa, one can synthetized a AAAA record for the string
+ [X].dynrev.arpa. which value is
+ FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
+ a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
+
+
+3.4. Server side synthesis
+
+ If synthesis is done on the server side, PTR could be set not to use
+ the dynrev.arpa domain but the local domain name instead. It culd be
+ for instance dynrev.mydomain.com.
+
+ Note also that server side synthesis is not incompatible with
+ resolver side synthesis.
+
+
+
+4. IANA considerations
+
+ The dynrev.arpa. domain is reserved for the purpose of this document.
+
+
+
+5. Security considerations
+
+ Section 2. discusses the the interactions with DNSsec.
+
+
+
+6. Authors addresses
+
+ Alain Durand
+ SUN Microsystems, Inc
+ 17, Network Circle
+ UMPK17-202
+ Menlo Park, CA 94025
+ USA
+ Mail: Alain.Durand@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt
new file mode 100644
index 0000000..fa41e76
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-2929bis-01.txt
@@ -0,0 +1,928 @@
+
+INTERNET-DRAFT Donald E. Eastlake 3rd
+Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories
+Expires: February 2006 August 2005
+
+
+
+ Domain Name System (DNS) IANA Considerations
+ ------ ---- ------ ----- ---- --------------
+ <draft-ietf-dnsext-2929bis-01.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 draft is unlimited. It is intended to become
+ the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
+ DNS 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 a "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
+
+ Internet Assigned Number Authority (IANA) parameter assignment
+ considerations are given for the allocation of Domain Name System
+ (DNS) classes, RR types, operation codes, error codes, RR header
+ bits, and AFSDB subtypes.
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 1]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+Table of Contents
+
+ Status of This Document....................................1
+ Abstract...................................................1
+
+ Table of Contents..........................................2
+
+ 1. Introduction............................................3
+ 2. DNS Query/Response Headers..............................3
+ 2.1 One Spare Bit?.........................................4
+ 2.2 Opcode Assignment......................................4
+ 2.3 RCODE Assignment.......................................5
+ 3. DNS Resource Records....................................6
+ 3.1 RR TYPE IANA Considerations............................7
+ 3.1.1 DNS TYPE Allocation Policy...........................8
+ 3.1.2 Special Note on the OPT RR...........................9
+ 3.1.3 The AFSDB RR Subtype Field...........................9
+ 3.2 RR CLASS IANA Considerations...........................9
+ 3.3 RR NAME Considerations................................11
+ 4. Security Considerations................................11
+
+ Appendix: Changes from RFC 2929...........................12
+
+ Copyright and Disclaimer..................................13
+ Normative References......................................13
+ Informative References....................................14
+
+ Authors Addresses.........................................16
+ Expiration and File Name..................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 2]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+1. Introduction
+
+ The Domain Name System (DNS) provides replicated distributed secure
+ hierarchical databases which hierarchically store "resource records"
+ (RRs) under domain names. DNS data is structured into CLASSes and
+ zones which can be independently maintained. See [RFC 1034, 1035,
+ 2136, 2181, 4033] familiarity with which is assumed.
+
+ This document provides, either directly or by reference, general IANA
+ parameter assignment considerations applying across DNS query and
+ response headers and all RRs. There may be additional IANA
+ considerations that apply to only a particular RR type or
+ query/response opcode. See the specific RFC defining that RR type or
+ query/response opcode for such considerations if they have been
+ defined, except for AFSDB RR considerations [RFC 1183] which are
+ included herein. This RFC obsoletes [RFC 2929].
+
+ IANA currently maintains a web page of DNS parameters. See
+ <http://www.iana.org/numbers.htm>.
+
+ "IETF Standards Action", "IETF Consensus", "Specification Required",
+ and "Private Use" are as defined in [RFC 2434].
+
+
+
+2. DNS Query/Response Headers
+
+ The header for DNS queries and responses contains field/bits in the
+ following diagram taken from [RFC 2136, 2929]:
+
+ 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 |AA|TC|RD|RA| Z|AD|CD| RCODE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | QDCOUNT/ZOCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ANCOUNT/PRCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | NSCOUNT/UPCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | ARCOUNT |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ The ID field identifies the query and is echoed in the response so
+ they can be matched.
+
+ The QR bit indicates whether the header is for a query or a response.
+
+
+D. Eastlake 3rd [Page 3]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+ The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
+ only in queries or only in responses, depending on the bit. However,
+ many DNS implementations copy the query header as the initial value
+ of the response header without clearing bits. Thus any attempt to
+ use a "query" bit with a different meaning in a response or to define
+ a query meaning for a "response" bit is dangerous given existing
+ implementation. Such meanings may only be assigned by an IETF
+ Standards Action.
+
+ The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
+ authority count (NSCOUNT), and additional information count (ARCOUNT)
+ express the number of records in each section for all opcodes except
+ Update. These fields have the same structure and data type for
+ Update but are instead the counts for the zone (ZOCOUNT),
+ prerequisite (PRCOUNT), update (UPCOUNT), and additional information
+ (ARCOUNT) sections.
+
+
+
+2.1 One Spare Bit?
+
+ There have been ancient DNS implementations for which the Z bit being
+ on in a query meant that only a response from the primary server for
+ a zone is acceptable. It is believed that current DNS
+ implementations ignore this bit.
+
+ Assigning a meaning to the Z bit requires an IETF Standards Action.
+
+
+
+2.2 Opcode Assignment
+
+ Currently DNS OpCodes are assigned as follows:
+
+ OpCode Name Reference
+
+ 0 Query [RFC 1035]
+ 1 IQuery (Inverse Query, Obsolete) [RFC 3425]
+ 2 Status [RFC 1035]
+ 3 available for assignment
+ 4 Notify [RFC 1996]
+ 5 Update [RFC 2136]
+ 6-15 available for assignment
+
+ New OpCode assignments require an IETF Standards Action as modified
+ by [RFC 4020].
+
+
+
+
+
+
+D. Eastlake 3rd [Page 4]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+2.3 RCODE Assignment
+
+ It would appear from the DNS header above that only four bits of
+ RCODE, or response/error code are available. However, RCODEs can
+ appear not only at the top level of a DNS response but also inside
+ OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
+ The OPT RR provides an eight bit extension resulting in a 12 bit
+ RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
+
+ Error codes appearing in the DNS header and in these three RR types
+ all refer to the same error code space with the single exception of
+ error code 16 which has a different meaning in the OPT RR from its
+ meaning in other contexts. See table below.
+
+ RCODE Name Description Reference
+ Decimal
+ Hexadecimal
+ 0 NoError No Error [RFC 1035]
+ 1 FormErr Format Error [RFC 1035]
+ 2 ServFail Server Failure [RFC 1035]
+ 3 NXDomain Non-Existent Domain [RFC 1035]
+ 4 NotImp Not Implemented [RFC 1035]
+ 5 Refused Query Refused [RFC 1035]
+ 6 YXDomain Name Exists when it should not [RFC 2136]
+ 7 YXRRSet RR Set Exists when it should not [RFC 2136]
+ 8 NXRRSet RR Set that should exist does not [RFC 2136]
+ 9 NotAuth Server Not Authoritative for zone [RFC 2136]
+ 10 NotZone Name not contained in zone [RFC 2136]
+ 11 - 15 Available for assignment
+ 16 BADVERS Bad OPT Version [RFC 2671]
+ 16 BADSIG TSIG Signature Failure [RFC 2845]
+ 17 BADKEY Key not recognized [RFC 2845]
+ 18 BADTIME Signature out of time window [RFC 2845]
+ 19 BADMODE Bad TKEY Mode [RPC 2930]
+ 20 BADNAME Duplicate key name [RPF 2930]
+ 21 BADALG Algorithm not supported [RPF 2930]
+
+ 22 - 3,840
+ 0x0016 - 0x0F00 Available for assignment
+
+ 3,841 - 4,095
+ 0x0F01 - 0x0FFF Private Use
+
+ 4,096 - 65,534
+ 0x1000 - 0xFFFE Available for assignment
+
+ 65,535
+ 0xFFFF Reserved, can only be allocated by an IETF
+ Standards Action.
+
+
+
+D. Eastlake 3rd [Page 5]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+ Since it is important that RCODEs be understood for interoperability,
+ assignment of new RCODE listed above as "available for assignment"
+ requires an IETF Consensus.
+
+
+
+3. DNS Resource Records
+
+ All RRs have the same top level format shown in the figure below
+ taken from [RFC 1035]:
+
+ 1 1 1 1 1 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | |
+ / /
+ / NAME /
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | TYPE |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | CLASS |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | TTL |
+ | |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ | RDLENGTH |
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+ / RDATA /
+ / /
+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+ NAME is an owner name, i.e., the name of the node to which this
+ resource record pertains. NAMEs are specific to a CLASS as described
+ in section 3.2. NAMEs consist of an ordered sequence of one or more
+ labels each of which has a label type [RFC 1035, 2671].
+
+ TYPE is a two octet unsigned integer containing one of the RR TYPE
+ codes. See section 3.1.
+
+ CLASS is a two octet unsigned integer containing one of the RR CLASS
+ codes. See section 3.2.
+
+ TTL is a four octet (32 bit) bit unsigned integer that specifies the
+ number of seconds that the resource record may be cached before the
+ source of the information should again be consulted. Zero is
+ interpreted to mean that the RR can only be used for the transaction
+ in progress.
+
+ RDLENGTH is an unsigned 16 bit integer that specifies the length in
+
+
+D. Eastlake 3rd [Page 6]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+ octets of the RDATA field.
+
+ RDATA is a variable length string of octets that constitutes the
+ resource. The format of this information varies according to the TYPE
+ and in some cases the CLASS of the resource record.
+
+
+
+3.1 RR TYPE IANA Considerations
+
+ There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
+ and MetaTYPEs.
+
+ Data TYPEs are the primary means of storing data. QTYPES can only be
+ used in queries. Meta-TYPEs designate transient data associated with
+ an particular DNS message and in some cases can also be used in
+ queries. Thus far, data TYPEs have been assigned from 1 upwards plus
+ the block from 100 through 103 while Q and Meta Types have been
+ assigned from 255 downwards except for the OPT Meta-RR which is
+ assigned TYPE 41. There have been DNS implementations which made
+ caching decisions based on the top bit of the bottom byte of the RR
+ TYPE.
+
+ There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
+ [RFC 2845], and TKEY [RFC 2930].
+
+ There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
+ AXFR, and IXFR.
+
+ Considerations for the allocation of new RR TYPEs are as follows:
+
+ Decimal
+ Hexadecimal
+
+ 0
+ 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
+ 2535] and in other circumstances and must never be allocated
+ for ordinary use.
+
+ 1 - 127
+ 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
+ TYPEs by the DNS TYPE Allocation Policy as specified in
+ section 3.1.1.
+
+ 128 - 255
+ 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
+ Meta TYPEs by the DNS TYPE Allocation Policy as specified in
+ section 3.1.1.
+
+
+
+
+D. Eastlake 3rd [Page 7]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+ 256 - 32,767
+ 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
+ TYPE Allocation Policy as specified in section 3.1.1.
+
+ 32,768 - 65,279
+ 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
+
+ 65,280 - 65534
+ 0xFF00 - 0xFFFE - Private Use.
+
+ 65,535
+ 0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
+
+
+
+3.1.1 DNS TYPE Allocation Policy
+
+ Parameter values specified above as assigned based on DNS TYPE
+ Allocation Policy. That is, Expert Review with the additional
+ requirement that the review be based on a complete template as
+ specified below which has been posted for three weeks to the
+ namedroppers@ops.ietf.org mailing list.
+
+ Partial or draft templates may be posted with the intend of
+ soliciting feedback.
+
+
+ DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
+
+ Date:
+
+ Name and email of originator:
+
+ Pointer to internet-draft or other document giving a detailed
+ description of the protocol use of the new RR Type:
+
+ What need is the new RR TYPE intended to fix?
+
+ What existing RR TYPE(s) come closest to filling that need and why are
+ they unsatisfactory?
+
+ Does the proposed RR TYPR require special handling within the DNS
+ different from an Unknown RR TYPE?
+
+ Comments:
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 8]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+3.1.2 Special Note on the OPT RR
+
+ The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
+ primary purpose is to extend the effective field size of various DNS
+ fields including RCODE, label type, OpCode, flag bits, and RDATA
+ size. In particular, for resolvers and servers that recognize it, it
+ extends the RCODE field from 4 to 12 bits.
+
+
+
+3.1.3 The AFSDB RR Subtype Field
+
+ The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
+ RDATA field structure as the MX RR but the 16 bit unsigned integer
+ field at the beginning of the RDATA is interpreted as a subtype as
+ follows:
+
+ Decimal
+ Hexadecimal
+
+ 0
+ 0x0000 - Allocation requires IETF Standards Action.
+
+ 1
+ 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
+
+ 2
+ 0x0002 - DCE/NCA root cell directory node [RFC 1183].
+
+ 3 - 65,279
+ 0x0003 - 0xFEFF - Allocation by IETF Consensus.
+
+ 65,280 - 65,534
+ 0xFF00 - 0xFFFE - Private Use.
+
+ 65,535
+ 0xFFFF - Reserved, allocation requires IETF Standards Action.
+
+
+
+3.2 RR CLASS IANA Considerations
+
+ DNS CLASSes have been little used but constitute another dimension of
+ the DNS distributed database. In particular, there is no necessary
+ relationship between the name space or root servers for one CLASS and
+ those for another CLASS. The same name can have completely different
+ meanings in different CLASSes; however, the label types are the same
+ and the null label is usable only as root in every CLASS. However,
+ as global networking and DNS have evolved, the IN, or Internet, CLASS
+ has dominated DNS use.
+
+
+D. Eastlake 3rd [Page 9]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+ There are two subcategories of DNS CLASSes: normal data containing
+ classes and QCLASSes that are only meaningful in queries or updates.
+
+ The current CLASS assignments and considerations for future
+ assignments are as follows:
+
+ Decimal
+ Hexadecimal
+
+ 0
+ 0x0000 - Reserved, assignment requires an IETF Standards Action.
+
+ 1
+ 0x0001 - Internet (IN).
+
+ 2
+ 0x0002 - Available for assignment by IETF Consensus as a data CLASS.
+
+ 3
+ 0x0003 - Chaos (CH) [Moon 1981].
+
+ 4
+ 0x0004 - Hesiod (HS) [Dyer 1987].
+
+ 5 - 127
+ 0x0005 - 0x007F - available for assignment by IETF Consensus for data
+ CLASSes only.
+
+ 128 - 253
+ 0x0080 - 0x00FD - available for assignment by IETF Consensus for
+ QCLASSes only.
+
+ 254
+ 0x00FE - QCLASS None [RFC 2136].
+
+ 255
+ 0x00FF - QCLASS Any [RFC 1035].
+
+ 256 - 32,767
+ 0x0100 - 0x7FFF - Assigned by IETF Consensus.
+
+ 32,768 - 65,279
+ 0x8000 - 0xFEFF - Assigned based on Specification Required as defined
+ in [RFC 2434].
+
+ 65,280 - 65,534
+ 0xFF00 - 0xFFFE - Private Use.
+
+ 65,535
+ 0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
+
+
+D. Eastlake 3rd [Page 10]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+3.3 RR NAME Considerations
+
+ DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
+ NAME is "ROOT" which is the zero length label. By definition, the
+ null or ROOT label can not be used for any other NAME purpose.
+
+ At the present time, there are two categories of label types, data
+ labels and compression labels. Compression labels are pointers to
+ data labels elsewhere within an RR or DNS message and are intended to
+ shorten the wire encoding of NAMEs. The two existing data label
+ types are sometimes referred to as Text and Binary. Text labels can,
+ in fact, include any octet value including zero value octets but most
+ current uses involve only [US-ASCII]. For retrieval, Text labels are
+ defined to treat ASCII upper and lower case letter codes as matching
+ [insensitive]. Binary labels are bit sequences [RFC 2673]. The
+ Binary label type is Experimental [RFC 3363].
+
+ IANA considerations for label types are given in [RFC 2671].
+
+ NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
+ 1981] CLASSes are essentially for local use. The IN or Internet
+ CLASS is thus the only DNS CLASS in global use on the Internet at
+ this time.
+
+ A somewhat out-of-date description of name allocation in the IN Class
+ is given in [RFC 1591]. Some information on reserved top level
+ domain names is in BCP 32 [RFC 2606].
+
+
+
+4. Security Considerations
+
+ This document addresses IANA considerations in the allocation of
+ general DNS parameters, not security. See [RFC 4033, 4034, 4035] for
+ secure DNS considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 11]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+Appendix: Changes from RFC 2929
+
+ RFC Editor: This Appendix should be deleted for publication.
+
+ Changes from RFC 2929 to this draft:
+
+ 1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
+ Allocation Policy" and add the specification of that policy. Change
+ some remaining "IETF Standards Action" allocation requirements to say
+ "as modified by [RFC 4020]".
+
+ 2. Updated various RFC references.
+
+ 3. Mentioned that the Binary label type is now Experimental and
+ IQuery is Obsolete.
+
+ 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
+ IETF Standards Action required.
+
+ 5. Add an IANA allocation policy for the AFSDB RR Subtype field.
+
+ 6. Addition of reference to case insensitive draft.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 12]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+Copyright and Disclaimer
+
+ Copyright (C) The Internet Society (2005). 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.
+
+
+
+Normative References
+
+ [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
+ Specifications", STD 13, RFC 1035, November 1987.
+
+ [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
+ Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
+
+ [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
+ Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+ [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
+ "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+ April 1997.
+
+ [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+ [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
+ RFC 2673, August 1999.
+
+ [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+ Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
+ RFC 2845, May 2000.
+
+
+D. Eastlake 3rd [Page 13]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+ [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
+ RR)", September 2000.
+
+ [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+ Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
+ the Domain Name System (DNS)", RFC 3363, August 2002.
+
+ [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+ 2002.
+
+ [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
+ Standards Track Code Points", BCP 100, RFC 4020, February 2005.
+
+ [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements", RFC 4033, March
+ 2005.
+
+ [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Protocol Modifications for the DNS Security Extensions", RFC
+ 4035, March 2005.
+
+ [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
+ X3.4, American National Standards Institute: New York, 1968.
+
+
+
+Informative References
+
+ [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
+ Technical Plan - Name Service, April 1987,
+
+ [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
+ Institute of Technology Artificial Intelligence Laboratory, June
+ 1981.
+
+ [RFC 1591] - Postel, J., "Domain Name System Structure and
+ Delegation", RFC 1591, March 1994.
+
+ [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
+ "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
+ September 2000.
+
+ [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+ Names", RFC 2606, June 1999.
+
+ [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
+
+
+D. Eastlake 3rd [Page 14]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+ Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
+ work in progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 15]
+
+
+INTERNET-DRAFT DNS IANA Considerations August 2005
+
+
+Authors Addresses
+
+ Donald E. Eastlake 3rd
+ Motorola Laboratories
+ 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 February 2006.
+
+ Its file name is draft-ietf-dnsext-2929bis-01.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 16]
+
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
new file mode 100644
index 0000000..f0ce70a
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
@@ -0,0 +1,393 @@
+
+
+
+INTERNET-DRAFT Andreas Gustafsson
+draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc.
+ November 2002
+
+
+ DNS Zone Transfer Protocol Clarifications
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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.
+
+Abstract
+
+ In the Domain Name System, zone data is replicated among
+ authoritative DNS servers by means of the "zone transfer" protocol,
+ also known as the "AXFR" protocol. This memo clarifies, updates, and
+ adds missing detail to the original AXFR protocol specification in
+ RFC1034.
+
+1. Introduction
+
+ The original definition of the DNS zone transfer protocol consists of
+ a single paragraph in [RFC1034] section 4.3.5 and some additional
+ notes in [RFC1035] section 6.3. It is not sufficiently detailed to
+ serve as the sole basis for constructing interoperable
+ implementations. This document is an attempt to provide a more
+ complete definition of the protocol. Where the text in RFC1034
+ conflicts with existing practice, the existing practice has been
+ codified in the interest of interoperability.
+
+
+
+
+Expires May 2003 [Page 1]
+
+draft-ietf-dnsext-axfr-clarify-05.txt November 2002
+
+
+ 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].
+
+2. The zone transfer request
+
+ To initiate a zone transfer, the slave server sends a zone transfer
+ request to the master server over a reliable transport such as TCP.
+ The form of this request is specified in sufficient detail in RFC1034
+ and needs no further clarification.
+
+ Implementers are advised that one server implementation in widespread
+ use sends AXFR requests where the TCP message envelope size exceeds
+ the DNS request message size by two octets.
+
+3. The zone transfer response
+
+ If the master server is unable or unwilling to provide a zone
+ transfer, it MUST respond with a single DNS message containing an
+ appropriate RCODE other than NOERROR. If the master is not
+ authoritative for the requested zone, the RCODE SHOULD be 9
+ (NOTAUTH).
+
+ Slave servers should note that some master server implementations
+ will simply close the connection when denying the slave access to the
+ zone. Therefore, slaves MAY interpret an immediate graceful close of
+ the TCP connection as equivalent to a "Refused" response (RCODE 5).
+
+ If a zone transfer can be provided, the master server sends one or
+ more DNS messages containing the zone data as described below.
+
+3.1. Multiple answers per message
+
+ The zone data in a zone transfer response is a sequence of answer
+ RRs. These RRs are transmitted in the answer section(s) of one or
+ more DNS response messages.
+
+ The AXFR protocol definition in RFC1034 does not make a clear
+ distinction between response messages and answer RRs. Historically,
+ DNS servers always transmitted a single answer RR per message. This
+ encoding is wasteful due to the overhead of repeatedly sending DNS
+ message headers and the loss of domain name compression
+ opportunities. To improve efficiency, some newer servers support a
+ mode where multiple RRs are transmitted in a single DNS response
+ message.
+
+ A master MAY transmit multiple answer RRs per response message up to
+ the largest number that will fit within the 65535 byte limit on TCP
+
+
+
+Expires May 2003 [Page 2]
+
+draft-ietf-dnsext-axfr-clarify-05.txt November 2002
+
+
+ DNS message size. In the case of a small zone, this can cause the
+ entire transfer to be transmitted in a single response message.
+
+ Slaves MUST accept messages containing any number of answer RRs. For
+ compatibility with old slaves, masters that support sending multiple
+ answers per message SHOULD be configurable to revert to the
+ historical mode of one answer per message, and the configuration
+ SHOULD be settable on a per-slave basis.
+
+3.2. DNS message header contents
+
+ RFC1034 does not specify the contents of the DNS message header of
+ the zone transfer response messages. The header of each message MUST
+ be as follows:
+
+ ID Copy from request
+ QR 1
+ OPCODE QUERY
+ AA 1, but MAY be 0 when RCODE is not NOERROR
+ TC 0
+ RD Copy from request, or 0
+ RA Set according to availability of recursion, or 0
+ Z 0
+ AD 0
+ CD 0
+ RCODE NOERROR on success, error code otherwise
+
+ The slave MUST check the RCODE in each message and abort the transfer
+ if it is not NOERROR. It SHOULD check the ID of the first message
+ received and abort the transfer if it does not match the ID of the
+ request. The ID SHOULD be ignored in subsequent messages, and fields
+ other than RCODE and ID SHOULD be ignored in all messages, to ensure
+ interoperability with certain older implementations which transmit
+ incorrect or arbitrary values in these fields.
+
+3.3. Additional section and SIG processing
+
+ Zone transfer responses are not subject to any kind of additional
+ section processing or automatic inclusion of SIG records. SIG RRs in
+ the zone data are treated exactly the same as any other RR type.
+
+3.4. The question section
+
+ RFC1034 does not specify whether zone transfer response messages have
+ a question section or not. The initial message of a zone transfer
+ response SHOULD have a question section identical to that in the
+ request. Subsequent messages SHOULD NOT have a question section,
+ though the final message MAY. The receiving slave server MUST accept
+
+
+
+Expires May 2003 [Page 3]
+
+draft-ietf-dnsext-axfr-clarify-05.txt November 2002
+
+
+ any combination of messages with and without a question section.
+
+3.5. The authority section
+
+ The master server MUST transmit messages with an empty authority
+ section. Slaves MUST ignore any authority section contents they may
+ receive from masters that do not comply with this requirement.
+
+3.6. The additional section
+
+ The additional section MAY contain additional RRs such as transaction
+ signatures. The slave MUST ignore any unexpected RRs in the
+ additional section. It MUST NOT treat additional section RRs as zone
+ data.
+
+4. Zone data
+
+ The purpose of the zone transfer mechanism is to exactly replicate at
+ each slave the set of RRs associated with a particular zone at its
+ primary master. An RR is associated with a zone by being loaded from
+ the master file of that zone at the primary master server, or by some
+ other, equivalent method for configuring zone data.
+
+ This replication shall be complete and unaltered, regardless of how
+ many and which intermediate masters/slaves are involved, and
+ regardless of what other zones those intermediate masters/slaves do
+ or do not serve, and regardless of what data may be cached in
+ resolvers associated with the intermediate masters/slaves.
+
+ Therefore, in a zone transfer the master MUST send exactly those
+ records that are associated with the zone, whether or not their owner
+ names would be considered to be "in" the zone for purposes of
+ resolution, and whether or not they would be eligible for use as glue
+ in responses. The transfer MUST NOT include any RRs that are not
+ associated with the zone, such as RRs associated with zones other
+ than the one being transferred or present in the cache of the local
+ resolver, even if their owner names are in the zone being transferred
+ or are pointed to by NS records in the zone being transferred.
+
+ The slave MUST associate the RRs received in a zone transfer with the
+ specific zone being transferred, and maintain that association for
+ purposes of acting as a master in outgoing transfers.
+
+5. Transmission order
+
+ RFC1034 states that "The first and last messages must contain the
+ data for the top authoritative node of the zone". This is not
+ consistent with existing practice. All known master implementations
+
+
+
+Expires May 2003 [Page 4]
+
+draft-ietf-dnsext-axfr-clarify-05.txt November 2002
+
+
+ send, and slave implementations expect to receive, the zone's SOA RR
+ as the first and last record of the transfer.
+
+ Therefore, the quoted sentence is hereby superseded by the sentence
+ "The first and last RR transmitted must be the SOA record of the
+ zone".
+
+ The initial and final SOA record MUST be identical, with the possible
+ exception of case and compression. In particular, they MUST have the
+ same serial number. The slave MUST consider the transfer to be
+ complete when, and only when, it has received the message containing
+ the second SOA record.
+
+ The transmission order of all other RRs in the zone is undefined.
+ Each of them SHOULD be transmitted only once, and slaves MUST ignore
+ any duplicate RRs received.
+
+6. Security Considerations
+
+ The zone transfer protocol as defined in [RFC1034] and clarified by
+ this memo does not have any built-in mechanisms for the slave to
+ securely verify the identity of the master server and the integrity
+ of the transferred zone data. The use of a cryptographic mechanism
+ for ensuring authenticity and integrity, such as TSIG [RFC2845],
+ IPSEC, or TLS, is RECOMMENDED.
+
+ The zone transfer protocol allows read-only public access to the
+ complete zone data. Since data in the DNS is public by definition,
+ this is generally acceptable. Sites that wish to avoid disclosing
+ their full zone data MAY restrict zone transfer access to authorized
+ slaves.
+
+ These clarifications are not believed to themselves introduce any new
+ security problems, nor to solve any existing ones.
+
+Acknowledgements
+
+ 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.
+
+References
+
+ [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
+ November 1987.
+
+
+
+
+Expires May 2003 [Page 5]
+
+draft-ietf-dnsext-axfr-clarify-05.txt November 2002
+
+
+ [RFC1035] - Domain Names - Implementation and Specifications, P.
+ Mockapetris, November 1987.
+
+ [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
+ S. Bradner, BCP 14, March 1997.
+
+ [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
+ Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
+
+Author's Address
+
+ Andreas Gustafsson
+ Nominum Inc.
+ 2385 Bay Rd
+ Redwood City, CA 94063
+ USA
+
+ Phone: +1 650 381 6004
+
+ Email: gson@nominum.com
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000 - 2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implmentation may be prepared, copied, published and
+ distributed, in whole or in part, without restriction of any kind,
+ provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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
+
+
+
+Expires May 2003 [Page 6]
+
+draft-ietf-dnsext-axfr-clarify-05.txt November 2002
+
+
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires May 2003 [Page 7]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
new file mode 100644
index 0000000..07749d9
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
@@ -0,0 +1,674 @@
+
+
+
+
+DNSEXT M. Stapp
+Internet-Draft Cisco Systems, Inc.
+Expires: September 1, 2006 T. Lemon
+ Nominum, Inc.
+ A. Gustafsson
+ Araneus Information Systems Oy
+ February 28, 2006
+
+
+ A DNS RR for Encoding DHCP Information (DHCID RR)
+ <draft-ietf-dnsext-dhcid-rr-12.txt>
+
+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 September 1, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ It is possible for DHCP clients to attempt to update the same DNS
+ FQDN or attempt to update a DNS FQDN that has been added to the DNS
+ for another purpose as they obtain DHCP leases. Whether the DHCP
+ server or the clients themselves perform the DNS updates, conflicts
+ can arise. To resolve such conflicts, "Resolution of DNS Name
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 1]
+
+Internet-Draft The DHCID RR February 2006
+
+
+ Conflicts" [1] proposes storing client identifiers in the DNS to
+ unambiguously associate domain names with the DHCP clients to which
+ they refer. This memo defines a distinct RR type for this purpose
+ for use by DHCP clients and servers, the "DHCID" RR.
+
+
+Table of Contents
+
+ 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.1. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 3
+ 3.2. DHCID Presentation Format . . . . . . . . . . . . . . . . 4
+ 3.3. The DHCID RR Identifier Type Codes . . . . . . . . . . . . 4
+ 3.4. The DHCID RR Digest Type Code . . . . . . . . . . . . . . 4
+ 3.5. Computation of the RDATA . . . . . . . . . . . . . . . . . 5
+ 3.5.1. Using the Client's DUID . . . . . . . . . . . . . . . 5
+ 3.5.2. Using the Client Identifier Option . . . . . . . . . . 5
+ 3.5.3. Using the Client's htype and chaddr . . . . . . . . . 6
+ 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.6.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 7
+ 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 7
+ 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
+ Intellectual Property and Copyright Statements . . . . . . . . . . 12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 2]
+
+Internet-Draft The DHCID RR February 2006
+
+
+1. 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 RFC 2119 [2].
+
+
+2. Introduction
+
+ A set of procedures to allow DHCP [6] [10] clients and servers to
+ automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
+ in "Resolution of DNS Name Conflicts" [1].
+
+ Conflicts can arise if multiple DHCP clients wish to use the same DNS
+ name or a DHCP client attempts to use a name added for another
+ purpose. To resolve such conflicts, "Resolution of DNS Name
+ Conflicts" [1] proposes storing client identifiers in the DNS to
+ unambiguously associate domain names with the DHCP clients using
+ them. In the interest of clarity, it is preferable for this DHCP
+ information to use a distinct RR type. This memo defines a distinct
+ RR for this purpose for use by DHCP clients or servers, the "DHCID"
+ RR.
+
+ In order to obscure potentially sensitive client identifying
+ information, the data stored is the result of a one-way SHA-256 hash
+ computation. The hash includes information from the DHCP client's
+ message as well as the domain name itself, so that the data stored in
+ the DHCID RR will be dependent on both the client identification used
+ in the DHCP protocol interaction and the domain name. This means
+ that the DHCID RDATA will vary if a single client is associated over
+ time with more than one name. This makes it difficult to 'track' a
+ client as it is associated with various domain names.
+
+
+3. The DHCID RR
+
+ The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
+ DHCID RR is only defined in the IN class. DHCID RRs cause no
+ additional section processing. The DHCID RR is not a singleton type.
+
+3.1. DHCID RDATA format
+
+ The RDATA section of a DHCID RR in transmission contains RDLENGTH
+ octets of binary data. The format of this data and its
+ interpretation by DHCP servers and clients are described below.
+
+ DNS software should consider the RDATA section to be opaque. DHCP
+ clients or servers use the DHCID RR to associate a DHCP client's
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 3]
+
+Internet-Draft The DHCID RR February 2006
+
+
+ identity with a DNS name, so that multiple DHCP clients and servers
+ may deterministically perform dynamic DNS updates to the same zone.
+ From the updater's perspective, the DHCID resource record RDATA
+ consists of a 2-octet identifier type, in network byte order,
+ followed by a 1-octet digest type, followed by one or more octets
+ representing the actual identifier:
+
+ < 2 octets > Identifier type code
+ < 1 octet > Digest type code
+ < n octets > Digest (length depends on digest type)
+
+3.2. DHCID Presentation Format
+
+ In DNS master files, the RDATA is represented as a single block in
+ base 64 encoding identical to that used for representing binary data
+ in RFC 3548 [7]. The data may be divided up into any number of white
+ space separated substrings, down to single base 64 digits, which are
+ concatenated to form the complete RDATA. These substrings can span
+ lines using the standard parentheses.
+
+3.3. The DHCID RR Identifier Type Codes
+
+ The DHCID RR Identifier Type Code specifies what data from the DHCP
+ client's request was used as input into the hash function. The
+ identifier type codes are defined in a registry maintained by IANA,
+ as specified in Section 7. The initial list of assigned values for
+ the identifier type code is:
+
+ 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
+ 0x0001 = The data octets (i.e., the Type and Client-Identifier
+ fields) from a DHCPv4 client's Client Identifier option [9].
+ 0x0002 = The client's DUID (i.e., the data octets of a DHCPv6
+ client's Client Identifier option [10] or the DUID field from a
+ DHCPv4 client's Client Identifier option [12]).
+
+ 0x0003 - 0xfffe = Available to be assigned by IANA.
+
+ 0xffff = RESERVED
+
+3.4. The DHCID RR Digest Type Code
+
+ The DHCID RR Digest Type Code is an identifier for the digest
+ algorithm used. The digest is calculated over an identifier and the
+ canonical FQDN as described in the next section.
+
+ The digest type codes are defined in a registry maintained by IANA,
+ as specified in Section 7. The initial list of assigned values for
+ the digest type codes is: value 0 is reserved and value 1 is SHA-256.
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 4]
+
+Internet-Draft The DHCID RR February 2006
+
+
+ Reserving other types requires IETF standards action. Defining new
+ values will also require IETF standards action to document how DNS
+ updaters are to deal with multiple digest types.
+
+3.5. Computation of the RDATA
+
+ The DHCID RDATA is formed by concatenating the 2-octet identifier
+ type code with variable-length data.
+
+ The RDATA for all type codes other than 0xffff, which is reserved for
+ future expansion, is formed by concatenating the 2-octet identifier
+ type code, the 1-octet digest type code, and the digest value (32
+ octets for SHA-256).
+
+ < identifier-type > < digest-type > < digest >
+
+ The input to the digest hash function is defined to be:
+
+ digest = SHA-256(< identifier > < FQDN >)
+
+ The FQDN is represented in the buffer in unambiguous canonical form
+ as described in RFC 4034 [8], section 6.1. The identifier type code
+ and the identifier are related as specified in Section 3.3: the
+ identifier type code describes the source of the identifier.
+
+ A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
+ option is present in the DHCPv4 messages and it is encoded as
+ specified in [12]. Otherwise, the updater uses 0x0001 if a Client
+ Identifier option is present and 0x0000 if not.
+
+ A DHCPv6 updater always uses the 0x0002 type code.
+
+3.5.1. Using the Client's DUID
+
+ When the updater is using the Client's DUID (either from a DHCPv6
+ Client Identifier option or from a portion of the DHCPv4 Client
+ Identifier option encoded as specified in [12]), the first two octets
+ of the DHCID RR MUST be 0x0002, in network byte order. The third
+ octet is the digest type code (1 for SHA-256). The rest of the DHCID
+ RR MUST contain the results of computing the SHA-256 hash across the
+ octets of the DUID followed by the FQDN.
+
+3.5.2. Using the Client Identifier Option
+
+ When the updater is using the DHCPv4 Client Identifier option sent by
+ the client in its DHCPREQUEST message, the first two octets of the
+ DHCID RR MUST be 0x0001, in network byte order. The third octet is
+ the digest type code (1 for SHA-256). The rest of the DHCID RR MUST
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 5]
+
+Internet-Draft The DHCID RR February 2006
+
+
+ contain the results of computing the SHA-256 hash across the data
+ octets (i.e., the Type and Client-Identifier fields) of the option,
+ followed by the FQDN.
+
+3.5.3. Using the Client's htype and chaddr
+
+ When the updater is using the client's link-layer address as the
+ identifier, the first two octets of the DHCID RDATA MUST be zero.
+ The third octet is the digest type code (1 for SHA-256). To generate
+ the rest of the resource record, the updater computes a one-way hash
+ using the SHA-256 algorithm across a buffer containing the client's
+ network hardware type, link-layer address, and the FQDN data.
+ Specifically, the first octet of the buffer contains the network
+ hardware type as it appeared in the DHCP 'htype' field of the
+ client's DHCPREQUEST message. All of the significant octets of the
+ 'chaddr' field in the client's DHCPREQUEST message follow, in the
+ same order in which the octets appear in the DHCPREQUEST message.
+ The number of significant octets in the 'chaddr' field is specified
+ in the 'hlen' field of the DHCPREQUEST message. The FQDN data, as
+ specified above, follows.
+
+3.6. Examples
+
+3.6.1. Example 1
+
+ A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
+ Ethernet MAC address 01:02:03:04:05:06 using domain name
+ "client.example.com" uses the client's link-layer address to identify
+ the client. The DHCID RDATA is composed by setting the two type
+ octets to zero, the 1-octet digest type to 1 for SHA-256, and
+ performing an SHA-256 hash computation across a buffer containing the
+ Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
+ domain name (represented as specified in Section 3.5).
+
+ client.example.com. A 10.0.0.1
+ client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
+ ytcKD//7es/deY= )
+
+ If the DHCID RR type is not supported, the RDATA would be encoded
+ [13] as:
+
+ \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
+ fffedeb3f75e6 )
+
+3.6.2. Example 2
+
+ A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
+ included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 6]
+
+Internet-Draft The DHCID RR February 2006
+
+
+ in its DHCP request. The server updates the name "chi.example.com"
+ on the client's behalf, and uses the DHCP client identifier option
+ data as input in forming a DHCID RR. The DHCID RDATA is formed by
+ setting the two type octets to the value 0x0001, the 1-octet digest
+ type to 1 for SHA-256, and performing a SHA-256 hash computation
+ across a buffer containing the seven octets from the client-id option
+ and the FQDN (represented as specified in Section 3.5).
+
+ chi.example.com. A 10.0.12.99
+ chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
+ L3b/NaiUDlW2No= )
+
+ If the DHCID RR type is not supported, the RDATA would be encoded
+ [13] as:
+
+ \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
+ 6a2503956d8da )
+
+3.6.3. Example 3
+
+ A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
+ which included the DHCPv6 client-identifier option data 00:01:00:06:
+ 41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The server
+ updates the name "chi6.example.com" on the client's behalf, and uses
+ the DHCP client identifier option data as input in forming a DHCID
+ RR. The DHCID RDATA is formed by setting the two type octets to the
+ value 0x0002, the 1-octet digest type to 1 for SHA-256, and
+ performing a SHA-256 hash computation across a buffer containing the
+ 14 octets from the client-id option and the FQDN (represented as
+ specified in Section 3.5).
+
+ chi6.example.com. AAAA 2000::1234:5678
+ chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
+ OjxfNuVAA2kjEA= )
+
+ If the DHCID RR type is not supported, the RDATA would be encoded
+ [13] as:
+
+ \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
+ b95000da48c40 )
+
+
+4. Use of the DHCID RR
+
+ This RR MUST NOT be used for any purpose other than that detailed in
+ "Resolution of DNS Name Conflicts" [1]. Although this RR contains
+ data that is opaque to DNS servers, the data must be consistent
+ across all entities that update and interpret this record.
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 7]
+
+Internet-Draft The DHCID RR February 2006
+
+
+ Therefore, new data formats may only be defined through actions of
+ the DHC Working Group, as a result of revising [1].
+
+
+5. Updater Behavior
+
+ The data in the DHCID RR allows updaters to determine whether more
+ than one DHCP client desires to use a particular FQDN. This allows
+ site administrators to establish policy about DNS updates. The DHCID
+ RR does not establish any policy itself.
+
+ Updaters use data from a DHCP client's request and the domain name
+ that the client desires to use to compute a client identity hash, and
+ then compare that hash to the data in any DHCID RRs on the name that
+ they wish to associate with the client's IP address. If an updater
+ discovers DHCID RRs whose RDATA does not match the client identity
+ that they have computed, the updater SHOULD conclude that a different
+ client is currently associated with the name in question. The
+ updater SHOULD then proceed according to the site's administrative
+ policy. That policy might dictate that a different name be selected,
+ or it might permit the updater to continue.
+
+
+6. Security Considerations
+
+ The DHCID record as such does not introduce any new security problems
+ into the DNS. In order to obscure the client's identity information,
+ a one-way hash is used. And, in order to make it difficult to
+ 'track' a client by examining the names associated with a particular
+ hash value, the FQDN is included in the hash computation. Thus, the
+ RDATA is dependent on both the DHCP client identification data and on
+ each FQDN associated with the client.
+
+ However, it should be noted that an attacker that has some knowledge,
+ such as of MAC addresses commonly used in DHCP client identification
+ data, may be able to discover the client's DHCP identify by using a
+ brute-force attack. Even without any additional knowledge, the
+ number of unknown bits used in computing the hash is typically only
+ 48 to 80.
+
+ Administrators should be wary of permitting unsecured DNS updates to
+ zones, whether or not they are exposed to the global Internet. Both
+ DHCP clients and servers SHOULD use some form of update
+ authentication (e.g., TSIG [11]) when performing DNS updates.
+
+
+7. IANA Considerations
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 8]
+
+Internet-Draft The DHCID RR February 2006
+
+
+ IANA is requested to allocate a DNS RR type number for the DHCID
+ record type.
+
+ This specification defines a new number-space for the 2-octet
+ identifier type codes associated with the DHCID RR. IANA is
+ requested to establish a registry of the values for this number-
+ space. Three initial values are assigned in Section 3.3, and the
+ value 0xFFFF is reserved for future use. New DHCID RR identifier
+ type codes are assigned through Standards Action, as defined in RFC
+ 2434 [5].
+
+ This specification defines a new number-space for the 1-octet digest
+ type codes associated with the DHCID RR. IANA is requested to
+ establish a registry of the values for this number-space. Two
+ initial values are assigned in Section 3.4. New DHCID RR digest type
+ codes are assigned through Standards Action, as defined in RFC 2434
+ [5].
+
+
+8. Acknowledgements
+
+ Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
+ Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
+ Volz for their review and suggestions.
+
+
+9. References
+
+9.1. Normative References
+
+ [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
+ DHCP Clients (draft-ietf-dhc-dns-resolution-*)", February 2006.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [4] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 9]
+
+Internet-Draft The DHCID RR February 2006
+
+
+9.2. Informative References
+
+ [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+ [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+ RFC 3548, July 2003.
+
+ [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ Extensions", RFC 2132, March 1997.
+
+ [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+ Carney, "Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6)", RFC 3315, July 2003.
+
+ [11] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
+ "Secret Key Transaction Authentication for DNS (TSIG)",
+ RFC 2845, May 2000.
+
+ [12] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
+ for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
+ RFC 4361, February 2006.
+
+ [13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+ Types", RFC 3597, September 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 10]
+
+Internet-Draft The DHCID RR February 2006
+
+
+Authors' Addresses
+
+ Mark Stapp
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ USA
+
+ Phone: 978.936.1535
+ Email: mjs@cisco.com
+
+
+ Ted Lemon
+ Nominum, Inc.
+ 950 Charter St.
+ Redwood City, CA 94063
+ USA
+
+ Email: mellon@nominum.com
+
+
+ Andreas Gustafsson
+ Araneus Information Systems Oy
+ Ulappakatu 1
+ 02320 Espoo
+ Finland
+
+ Email: gson@araneus.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 11]
+
+Internet-Draft The DHCID RR February 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.
+
+
+
+
+Stapp, et al. Expires September 1, 2006 [Page 12]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
new file mode 100644
index 0000000..438e800
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
@@ -0,0 +1,1397 @@
+DNS Extensions Working Group G. Sisson
+Internet-Draft B. Laurie
+Expires: January 11, 2006 Nominet
+ July 10, 2005
+
+
+ Derivation of DNS Name Predecessor and Successor
+ draft-ietf-dnsext-dns-name-p-s-00
+
+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 January 11, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document describes two methods for deriving the canonically-
+ ordered predecessor and successor of a DNS name. These methods may
+ be used for dynamic NSEC resource record synthesis, enabling
+ security-aware name servers to provide authenticated denial of
+ existence without disclosing other owner names in a DNSSEC-secured
+ zone.
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 1]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
+ 3. Absolute Method . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 4
+ 3.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 4
+ 4. Modified Method . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 6
+ 4.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 6
+ 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.1. Case Considerations . . . . . . . . . . . . . . . . . . . 7
+ 5.2. Choice of Range . . . . . . . . . . . . . . . . . . . . . 7
+ 5.3. Wild Card Considerations . . . . . . . . . . . . . . . . . 8
+ 5.4. Possible Modifications . . . . . . . . . . . . . . . . . . 8
+ 5.4.1. Restriction of Effective Maximum DNS Name Length . . . 8
+ 5.4.2. Use of Modified Method With Zones Containing
+ SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 9
+ 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6.1. Examples of Immediate Predecessors Using Absolute
+ Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6.2. Examples of Immediate Successors Using Absolute Method . . 13
+ 6.3. Examples of Predecessors Using Modified Method . . . . . . 19
+ 6.4. Examples of Successors Using Modified Method . . . . . . . 20
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
+ Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22
+ A.1. Changes from sisson-02 to ietf-00 . . . . . . . . . . . . 22
+ A.2. Changes from sisson-01 to sisson-02 . . . . . . . . . . . 23
+ A.3. Changes from sisson-00 to sisson-01 . . . . . . . . . . . 23
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
+ Intellectual Property and Copyright Statements . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 2]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+1. Introduction
+
+ One of the proposals for avoiding the exposure of zone information
+ during the deployment DNSSEC is dynamic NSEC resource record (RR)
+ synthesis. This technique is described in [I-D.ietf-dnsext-dnssec-
+ trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the
+ generation of NSEC RRs that just span the query name for non-existent
+ owner names. In order to do this, the DNS names which would occur
+ just prior to and just following a given query name must be
+ calculated in real time, as maintaining a list of all possible owner
+ names that might occur in a zone would be impracticable.
+
+ Section 6.1 of [RFC4034] defines canonical DNS name order. This
+ document does not amend or modify this definition. However, the
+ derivation of immediate predecessor and successor, while trivial, is
+ non-obvious. Accordingly, several methods are described here as an
+ aid to implementors and a reference to other interested parties.
+
+ This document describes two methods:
+
+ 1. An ``absolute method'', which returns the immediate predecessor
+ or successor of a domain name such that no valid DNS name could
+ exist between that DNS name and the predecessor or successor.
+
+ 2. A ``modified method'', which returns a predecessor and successor
+ which are more economical in size and computation. This method
+ is restricted to use with zones consisting only of single-label
+ owner names where a maximum-length owner name would not result in
+ a DNS name exceeding the maximum DNS name length. This is,
+ however, the type of zone for which the technique of online-
+ signing is most likely to be used.
+
+
+2. Notational Conventions
+
+ The following notational conventions are used in this document for
+ economy of expression:
+
+ N: An unspecified DNS name.
+
+ P(N): Immediate predecessor to N (absolute method).
+
+ S(N): Immediate successor to N (absolute method).
+
+ P'(N): Predecessor to N (modified method).
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 3]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ S'(N): Successor to N (modified method).
+
+
+3. Absolute Method
+
+ These derivations assume that all uppercase US-ASCII letters in N
+ have already been replaced by their corresponding lowercase
+ equivalents. Unless otherwise specified, processing stops after the
+ first step in which a condition is met.
+
+3.1. Derivation of DNS Name Predecessor
+
+ To derive P(N):
+
+ 1. If N is the same as the owner name of the zone apex, prepend N
+ repeatedly with labels of the maximum length possible consisting
+ of octets of the maximum sort value (e.g. 0xff) until N is the
+ maximum length possible; otherwise continue to the next step.
+
+ 2. If the least significant (left-most) label of N consists of a
+ single octet of the minimum sort value (e.g. 0x00), remove that
+ label; otherwise continue to the next step.
+
+ 3. If the least significant (right-most) octet in the least
+ significant (left-most) label of N is the minimum sort value,
+ remove the least significant octet and continue with step 5.
+
+ 4. Decrement the value of the least significant (right-most) octet,
+ skipping any values that correspond to uppercase US-ASCII
+ letters, and then append the label with as many octets as
+ possible of the maximum sort value. Continue to the next step.
+
+ 5. Prepend N repeatedly with labels of as long a length as possible
+ consisting of octets of the maximum sort value until N is the
+ maximum length possible.
+
+3.2. Derivation of DNS Name Successor
+
+ To derive S(N):
+
+ 1. If N is two or more octets shorter than the maximum DNS name
+ length, prepend N with a label containing a single octet of the
+ minimum sort value (e.g. 0x00); otherwise continue to the next
+ step.
+
+ 2. If N is one or more octets shorter than the maximum DNS name
+ length and the least significant (left-most) label is one or more
+ octets shorter than the maximum label length, append an octet of
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 4]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ the minimum sort value to the least significant label; otherwise
+ continue to the next step.
+
+ 3. Increment the value of the least significant (right-most) octet
+ in the least significant (left-most) label that is less than the
+ maximum sort value (e.g. 0xff), skipping any values that
+ correspond to uppercase US-ASCII letters, and then remove any
+ octets to the right of that one. If all octets in the label are
+ the maximum sort value, then continue to the next step.
+
+ 4. Remove the least significant (left-most) label. If N is now the
+ same as the owner name of the zone apex, do nothing. (This will
+ occur only if N is the maximum possible name in canonical DNS
+ name order, and thus has wrapped to the owner name of zone apex.)
+ Otherwise repeat starting at step 2.
+
+
+4. Modified Method
+
+ This method is for use with zones consisting only of single-label
+ owner names where an owner name consisting of label of maximum length
+ would not result in a DNS name which exceeded the maximum DNS name
+ length. This method is computationally simpler and returns values
+ which are more economical in size than the absolute method. It
+ differs from the absolute method detailed above in the following
+ ways:
+
+ 1. Step 1 of the derivation P(N) has been omitted as the existence
+ of the owner name of the zone apex never requires denial.
+
+ 2. A new step 1 has been introduced which removes unnecessary
+ labels.
+
+ 3. Step 4 of the derivation P(N) has been omitted as it is only
+ necessary for zones containing owner names consisting of more
+ than one label. This omission generally results in a significant
+ reduction of the length of derived predecessors.
+
+ 4. Step 1 of the derivation S(N) had been omitted as it is only
+ necessary for zones containing owner names consisting of more
+ than one label. This omission results in a tiny reduction of the
+ length of derived successors, and maintains consistency with the
+ modification of step 4 of the derivation P(N) described above.
+
+ 5. Steps 2 and 4 of the derivation S(N) have been modified to
+ eliminate checks for maximum DNS name length, as it is an
+ assumption of this method that no DNS name in the zone can exceed
+ the maximum DNS name length.
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 5]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ These derivations assume that all uppercase US-ASCII letters in N
+ have already been replaced by their corresponding lowercase
+ equivalents. Unless otherwise specified, processing stops after the
+ first step in which a condition is met.
+
+4.1. Derivation of DNS Name Predecessor
+
+ To derive P'(N):
+
+ 1. If N has more labels than the number of labels in the owner name
+ of the apex + 1, repeatedly remove the least significant (left-
+ most) label until N has no more labels than the number of labels
+ in the owner name of the apex + 1; otherwise continue to next
+ step.
+
+ 2. If the least significant (left-most) label of N consists of a
+ single octet of the minimum sort value (e.g. 0x00), remove that
+ label; otherwise continue to the next step.
+
+ 3. If the least significant (right-most) octet in the least
+ significant (left-most) label of N is the minimum sort value,
+ remove the least significant octet.
+
+ 4. Decrement the value of the least significant (right-most) octet,
+ skipping any values which correspond to uppercase US-ASCII
+ letters, and then append the label with as many octets as
+ possible of the maximum sort value.
+
+4.2. Derivation of DNS Name Successor
+
+ To derive S'(N):
+
+ 1. If N has more labels than the number of labels in the owner name
+ of the apex + 1, repeatedly remove the least significant (left-
+ most) label until N has no more labels than the number of labels
+ in the owner name of the apex + 1. Continue to next step.
+
+ 2. If the least significant (left-most) label of N is one or more
+ octets shorter than the maximum label length, append an octet of
+ the minimum sort value to the least significant label; otherwise
+ continue to the next step.
+
+ 3. Increment the value of the least significant (right-most) octet
+ in the least significant (left-most) label that is less than the
+ maximum sort value (e.g. 0xff), skipping any values which
+ correspond to uppercase US-ASCII letters, and then remove any
+ octets to the right of that one. If all octets in the label are
+ the maximum sort value, then continue to the next step.
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 6]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ 4. Remove the least significant (left-most) label. (This will occur
+ only if the least significant label is the maximum label length
+ and consists entirely of octets of the maximum sort value, and
+ thus has wrapped to the owner name of the zone apex.)
+
+
+5. Notes
+
+5.1. Case Considerations
+
+ Section 3.5 of [RFC1034] specifies that "while upper and lower case
+ letters are allowed in [DNS] names, no significance is attached to
+ the case". Additionally, Section 6.1 of [RFC4034] states that when
+ determining canonical DNS name order, "uppercase US-ASCII letters are
+ treated as if they were lowercase US-ASCII letters". Consequently,
+ values corresponding to US-ASCII uppercase letters must be skipped
+ when decrementing and incrementing octets in the derivations
+ described in Section 3.1 and Section 3.2.
+
+ The following pseudo-code is illustrative:
+
+ Decrement the value of an octet:
+
+ if (octet == '[') // '[' is just after uppercase 'Z'
+ octet = '@'; // '@' is just prior to uppercase 'A'
+ else
+ octet--;
+
+ Increment the value of an octet:
+
+ if (octet == '@') // '@' is just prior to uppercase 'A'
+ octet = '['; // '[' is just after uppercase 'Z'
+ else
+ octet++;
+
+5.2. Choice of Range
+
+ [RFC2181] makes the clarification that "any binary string whatever
+ can be used as the label of any resource record". Consequently the
+ minimum sort value may be set as 0x00 and the maximum sort value as
+ 0xff, and the range of possible values will be any DNS name which
+ contains octets of any value other than those corresponding to
+ uppercase US-ASCII letters.
+
+ However, if all owner names in a zone are in the letter-digit-hyphen,
+ or LDH, format specified in [RFC1034], it may be desirable to
+ restrict the range of possible values to DNS names containing only
+ LDH values. This has the effect of:
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 7]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ 1. making the output of tools such as `dig' and `nslookup' less
+ subject to confusion;
+
+ 2. minimising the impact that NSEC RRs containing DNS names with
+ non-LDH values (or non-printable values) might have on faulty DNS
+ resolver implementations; and
+
+ 3. preventing the possibility of results which are wildcard DNS
+ names (see Section 5.3).
+
+ This may be accomplished by using a minimum sort value of 0x1f (US-
+ ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
+ character lowercase `z'), and then skipping non-LDH, non-lowercase
+ values when incrementing or decrementing octets.
+
+5.3. Wild Card Considerations
+
+ Neither derivation avoids the possibility that the result may be a
+ DNS name containing a wildcard label, i.e. a label containing a
+ single octet with the value 0x2a (US-ASCII character `*'). With
+ additional tests, wildcard DNS names may be explicitly avoided;
+ alternatively, if the range of octet values can be restricted to
+ those corresponding to letter-digit-hyphen, or LDH, characters (see
+ Section 5.2), such DNS names will not occur.
+
+ Note that it is improbable that a result which is a wildcard DNS name
+ will occur unintentionally; even if one does occur either as the
+ owner name of, or in the RDATA of an NSEC RR, it is treated as a
+ literal DNS name with no special meaning.
+
+5.4. Possible Modifications
+
+5.4.1. Restriction of Effective Maximum DNS Name Length
+
+ [RFC1034] specifies that "the total number of octets that represent a
+ [DNS] name (i.e., the sum of all label octets and label lengths) is
+ limited to 255", including the null (zero-length) label which
+ represents the root. For the purpose of deriving predecessors and
+ successors during NSEC RR synthesis, the maximum DNS name length may
+ be effectively restricted to the length of the longest DNS name in
+ the zone. This will minimise the size of responses containing
+ synthesised NSEC RRs but, especially in the case of the modified
+ method, may result in some additional computational complexity.
+
+ Note that this modification will have the effect of revealing
+ information about the longest name in the zone. Moreover, when the
+ contents of the zone changes, e.g. during dynamic updates and zone
+ transfers, care must be taken to ensure that the effective maximum
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 8]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ DNS name length agrees with the new contents.
+
+5.4.2. Use of Modified Method With Zones Containing SRV RRs
+
+ Normally the modified method cannot be used in zones that contain
+ SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple
+ labels. However the use of SRV RRs can be accommodated by various
+ techniques. There are at least four possible ways to do this:
+
+ 1. Use conventional NSEC RRs for the region of the zone that
+ contains first-level labels beginning with the underscore (`_')
+ character. For the purposes of generating these NSEC RRs, the
+ existence of (possibly fictional) ownernames `9{63}' and `a'
+ could be assumed, providing a lower and upper bound for this
+ region. Then all queries where the QNAME doesn't exist but
+ contains a first-level label beginning with an underscore could
+ be handled using the normal DNSSEC protocol.
+
+ This approach would make it possible to enumerate all DNS names
+ in the zone containing a first-level label beginning with
+ underscore, including all SRV RRs, but this may be of less a
+ concern to the zone administrator than incurring the overhead of
+ the absolute method or of the following variants of the modified
+ method.
+
+ 2. The absolute method could be used for synthesising NSEC RRs for
+ all queries where the QNAME contains a leading underscore.
+ However this re-introduces the susceptibility of the absolute
+ method to denial of service activity, as an attacker could send
+ queries for an effectively inexhaustible supply of domain names
+ beginning with a leading underscore.
+
+ 3. A variant of the modified method could be used for synthesising
+ NSEC RRs for all queries where the QNAME contains a leading
+ underscore. This variant would assume that all predecessors and
+ successors to queries where the QNAME contains a leading
+ underscore may consist of two lablels rather than only one. This
+ introduces a little additional complexity without incurring the
+ full increase in response size and computational complexity as
+ the absolute method.
+
+ 4. Finally, a variant the modified method which assumes that all
+ owner names in the zone consist of one or two labels could be
+ used. However this negates much of the reduction in response
+ size of the modified method and may be nearly as computationally
+ complex as the absolute method.
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 9]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+6. Examples
+
+ In the following examples:
+
+ the owner name of the zone apex is "example.com.";
+
+ the range of octet values is 0x00 - 0xff excluding values
+ corresponding to uppercase US-ASCII letters; and
+
+ non-printable octet values are expressed as three-digit decimal
+ numbers preceded by a backslash (as specified in Section 5.1 of
+ [RFC1035]).
+
+6.1. Examples of Immediate Predecessors Using Absolute Method
+
+ Example of typical case:
+
+ P(foo.example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.fon\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
+
+ where {n} represents the number of repetitions of an octet.
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 10]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where least significant (left-most) label of DNS name
+ consists of a single octet of the minimum sort value:
+
+ P(\000.foo.example.com.) = foo.example.com.
+
+ Example where least significant (right-most) octet of least
+ significant (left-most) label has the minimum sort value:
+
+ P(foo\000.example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.foo.example.com.
+
+ or, in alternate notation:
+
+ \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 11]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where DNS name contains an octet which must be decremented by
+ skipping values corresponding to US-ASCII uppercase letters:
+
+ P(fo\[.example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.fo\@\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
+
+ where {n} represents the number of repetitions of an octet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 12]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where DNS name is the owner name of the zone apex, and
+ consequently wraps to the DNS name with the maximum possible sort
+ order in the zone:
+
+ P(example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+6.2. Examples of Immediate Successors Using Absolute Method
+
+ Example of typical case:
+
+ S(foo.example.com.) = \000.foo.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 13]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where DNS name is one octet short of the maximum DNS name
+ length:
+
+ N = fooooooooooooooooooooooooooooooooooooooooooooooo
+ .ooooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooo.ooooooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooo.ooooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+ or, in alternate notation:
+
+ fo{47}.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ fooooooooooooooooooooooooooooooooooooooooooooooo
+ \000.ooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooooo.ooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooooo.ooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oooo.example.com.
+
+ or, in alternate notation:
+
+ fo{47}\000.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 14]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where DNS name is the maximum DNS name length:
+
+ N = fooooooooooooooooooooooooooooooooooooooooooooooo
+ o.oooooooooooooooooooooooooooooooooooooooooooooo
+ ooooooooooooooooo.oooooooooooooooooooooooooooooo
+ ooooooooooooooooooooooooooooooooo.oooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ o.example.com.
+
+ or, in alternate notation:
+
+ fo{48}.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ fooooooooooooooooooooooooooooooooooooooooooooooo
+ p.oooooooooooooooooooooooooooooooooooooooooooooo
+ ooooooooooooooooo.oooooooooooooooooooooooooooooo
+ ooooooooooooooooooooooooooooooooo.oooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ o.example.com.
+
+ or, in alternate notation:
+
+ fo{47}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 15]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where DNS name is the maximum DNS name length and the least
+ significant (left-most) label has the maximum sort value:
+
+ N = \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.ooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooooo.ooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooooo.ooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oooo.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooop.oooooooooooooooooooooooooooooooo
+ ooooooooooooooooooooooooooooooo.oooooooooooooooo
+ ooooooooooooooooooooooooooooooooooooooooooooooo.
+ example.com.
+
+ or, in alternate notation:
+
+ o{62}p.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 16]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where DNS name is the maximum DNS name length and the eight
+ least significant (right-most) octets of the least significant (left-
+ most) label have the maximum sort value:
+
+ N = foooooooooooooooooooooooooooooooooooooooo\255
+ \255\255\255\255\255\255\255.ooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooo.ooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooo.ooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooo.example.com.
+
+ or, in alternate notation:
+
+ fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ fooooooooooooooooooooooooooooooooooooooop.oooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ ooooooooo.oooooooooooooooooooooooooooooooooooooo
+ ooooooooooooooooooooooooo.oooooooooooooooooooooo
+ ooooooooooooooooooooooooooooooooooooooooo.example.com.
+
+ or, in alternate notation:
+
+ fo{39}p.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 17]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where DNS name is the maximum DNS name length and contains an
+ octet which must be incremented by skipping values corresponding to
+ US-ASCII uppercase letters:
+
+ N = fooooooooooooooooooooooooooooooooooooooooooooooo
+ \@.ooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooo.ooooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooo.ooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oo.example.com.
+
+ or, in alternate notation:
+
+ fo{47}\@.o{63}.o{63}.o{63}.example.com.
+
+ S(N) =
+
+ fooooooooooooooooooooooooooooooooooooooooooooooo
+ \[.ooooooooooooooooooooooooooooooooooooooooooooo
+ oooooooooooooooooo.ooooooooooooooooooooooooooooo
+ oooooooooooooooooooooooooooooooooo.ooooooooooooo
+ oooooooooooooooooooooooooooooooooooooooooooooooo
+ oo.example.com.
+
+ or, in alternate notation:
+
+ fo{47}\[.o{63}.o{63}.o{63}.example.com.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 18]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where DNS name has the maximum possible sort order in the
+ zone, and consequently wraps to the owner name of the zone apex:
+
+ N = \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255.\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255.\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.example.com.
+
+ or, in alternate notation:
+
+ \255{49}.\255{63}.\255{63}.\255{63}.example.com.
+
+ S(N) = example.com.
+
+6.3. Examples of Predecessors Using Modified Method
+
+ Example of typical case:
+
+ P'(foo.example.com.) =
+
+ fon\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255.example.com.
+
+ or, in alternate notation:
+
+ fon\255{60}.example.com.
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 19]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where DNS name contains more labels than DNS names in the
+ zone:
+
+ P'(bar.foo.example.com.) = foo.example.com.
+
+ Example where least significant (right-most) octet of least
+ significant (left-most) label has the minimum sort value:
+
+ P'(foo\000.example.com.) = foo.example.com.
+
+ Example where least significant (left-most) label has the minimum
+ sort value:
+
+ P'(\000.example.com.) = example.com.
+
+ Example where DNS name is the owner name of the zone apex, and
+ consequently wraps to the DNS name with the maximum possible sort
+ order in the zone:
+
+ P'(example.com.) =
+
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255.example.com.
+
+ or, in alternate notation:
+
+ \255{63}.example.com.
+
+6.4. Examples of Successors Using Modified Method
+
+ Example of typical case:
+
+ S'(foo.example.com.) = foo\000.example.com.
+
+ Example where DNS name contains more labels than DNS names in the
+ zone:
+
+ S'(bar.foo.example.com.) = foo\000.example.com.
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 20]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+ Example where least significant (left-most) label has the maximum
+ sort value, and consequently wraps to the owner name of the zone
+ apex:
+
+ N = \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255.example.com.
+
+ or, in alternate notation:
+
+ \255{63}.example.com.
+
+ S'(N) = example.com.
+
+
+7. Security Considerations
+
+ The derivation of some predecessors/successors requires the testing
+ of more conditions than others. Consequently the effectiveness of a
+ denial-of-service attack may be enhanced by sending queries that
+ require more conditions to be tested. The modified method involves
+ the testing of fewer conditions than the absolute method and
+ consequently is somewhat less susceptible to this exposure.
+
+
+8. IANA Considerations
+
+ This document has no IANA actions.
+
+ Note to RFC Editor: This section is included to make it clear during
+ pre-publication review that this document has no IANA actions. It
+ may therefore be removed should it be published as an RFC.
+
+
+9. Acknowledgments
+
+ The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and
+ Niall O'Reilly for their review and input.
+
+
+10. References
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 21]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+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.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "Resource Records for the DNS Security Extensions",
+ RFC 4034, March 2005.
+
+10.2 Informative References
+
+ [I-D.ietf-dnsext-dnssec-online-signing]
+ Ihren, J. and S. Weiler, "Minimally Covering NSEC Records
+ and DNSSEC On-line Signing",
+ draft-ietf-dnsext-dnssec-online-signing-00 (work in
+ progress), May 2005.
+
+ [I-D.ietf-dnsext-dnssec-trans]
+ Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC
+ Transition Mechanisms",
+ draft-ietf-dnsext-dnssec-trans-02 (work in progress),
+ February 2005.
+
+
+Appendix A. Change History
+
+A.1. Changes from sisson-02 to ietf-00
+
+ o Added notes on use of SRV RRs with modified method.
+
+ o Changed reference from weiler-dnssec-online-signing to ietf-
+ dnsext-dnssec-online-signing.
+
+ o Changed reference from ietf-dnsext-dnssec-records to RFC 4034.
+
+ o Miscellaneous minor changes to text.
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 22]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+A.2. Changes from sisson-01 to sisson-02
+
+ o Added modified version of derivation (with supporting examples).
+
+ o Introduced notational conventions N, P(N), S(N), P'(N) and S'(N).
+
+ o Added clarification to derivations about when processing stops.
+
+ o Miscellaneous minor changes to text.
+
+A.3. Changes from sisson-00 to sisson-01
+
+ o Split step 3 of derivation of DNS name predecessor into two
+ distinct steps for clarity.
+
+ o Added clarifying text and examples related to the requirement to
+ avoid uppercase characters when decrementing or incrementing
+ octets.
+
+ o Added optimisation using restriction of effective maximum DNS name
+ length.
+
+ o Changed examples to use decimal rather than octal notation as per
+ [RFC1035].
+
+ o Corrected DNS name length of some examples.
+
+ o Added reference to weiler-dnssec-online-signing.
+
+ o Miscellaneous minor changes to text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 23]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+Authors' Addresses
+
+ Geoffrey Sisson
+ Nominet
+ Sandford Gate
+ Sandy Lane West
+ Oxford
+ OX4 6LB
+ GB
+
+ Phone: +44 1865 332339
+ Email: geoff@nominet.org.uk
+
+
+ Ben Laurie
+ Nominet
+ 17 Perryn Road
+ London
+ W3 7LR
+ GB
+
+ Phone: +44 20 8735 0686
+ Email: ben@algroup.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 24]
+
+Internet-Draft DNS Name Predecessor and Successor July 2005
+
+
+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 (2005). 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.
+
+
+
+
+Sisson & Laurie Expires January 11, 2006 [Page 25]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
new file mode 100644
index 0000000..bcc2b4e
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
@@ -0,0 +1,442 @@
+
+
+INTERNET-DRAFT Samuel Weiler
+Expires: June 2004 December 15, 2003
+Updates: RFC 2535, [DS]
+
+ Legacy Resolver Compatibility for Delegation Signer
+ draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 10 of RFC2026.
+
+ 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
+
+ Comments should be sent to the author or to the DNSEXT WG mailing
+ list: namedroppers@ops.ietf.org
+
+Abstract
+
+ As the DNS Security (DNSSEC) specifications have evolved, the
+ syntax and semantics of the DNSSEC resource records (RRs) have
+ changed. Many deployed nameservers understand variants of these
+ semantics. Dangerous interactions can occur when a resolver that
+ understands an earlier version of these semantics queries an
+ authoritative server that understands the new delegation signer
+ semantics, including at least one failure scenario that will cause
+ an unsecured zone to be unresolvable. This document changes the
+ type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
+ avoid those interactions.
+
+Changes between 05 and 06:
+
+ Signifigantly reworked the IANA section -- went back to one
+ algorithm registry.
+
+ Removed Diffie-Hellman from the list of zone-signing algorithms
+ (leaving only DSA, RSA/SHA-1, and private algorithms).
+
+ Added a DNSKEY flags field registry.
+
+Changes between 04 and 05:
+
+ IESG approved publication.
+
+ Cleaned up an internal reference in the acknowledgements section.
+
+ Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.
+
+ Changed the names of both new registries. Added algorithm
+ mnemonics to the new zone signing algorithm registry. Minor
+ rewording in the IANA section for clarity.
+
+ Cleaned up formatting of references. Replaced unknown-rr draft
+ references with RFC3597. Bumped DS version number.
+
+Changes between 03 and 04:
+
+ Clarified that RRSIG(0) may be defined by standards action.
+
+ Created a new algorithm registry and renamed the old algorithm
+ registry for SIG(0) only. Added references to the appropriate
+ crypto algorithm and format specifications.
+
+ Several minor rephrasings.
+
+Changes between 02 and 03:
+
+ KEY (as well as SIG) retained for SIG(0) use only.
+
+Changes between 01 and 02:
+
+ SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
+
+ Domain names embedded in NSECs and RRSIGs are not compressible and
+ are not downcased. Added unknown-rrs reference (as informative).
+
+ Simplified the last paragraph of section 3 (NSEC doesn't always
+ signal a negative answer).
+
+ Changed the suggested type code assignments.
+
+ Added 2119 reference.
+
+ Added definitions of "unsecure delegation" and "unsecure referral",
+ since they're not clearly defined elsewhere.
+
+ Moved 2065 to informative references, not normative.
+
+1. Introduction
+
+ The DNSSEC protocol has been through many iterations whose syntax
+ and semantics are not completely compatible. This has occurred as
+ part of the ordinary process of proposing a protocol, implementing
+ it, testing it in the increasingly complex and diverse environment
+ of the Internet, and refining the definitions of the initial
+ Proposed Standard. In the case of DNSSEC, the process has been
+ complicated by DNS's criticality and wide deployment and the need
+ to add security while minimizing daily operational complexity.
+
+ A weak area for previous DNS specifications has been lack of detail
+ in specifying resolver behavior, leaving implementors largely on
+ their own to determine many details of resolver function. This,
+ combined with the number of iterations the DNSSEC spec has been
+ through, has resulted in fielded code with a wide variety of
+ behaviors. This variety makes it difficult to predict how a
+ protocol change will be handled by all deployed resolvers. The
+ risk that a change will cause unacceptable or even catastrophic
+ failures makes it difficult to design and deploy a protocol change.
+ One strategy for managing that risk is to structure protocol
+ changes so that existing resolvers can completely ignore input that
+ might confuse them or trigger undesirable failure modes.
+
+ This document addresses a specific problem caused by Delegation
+ Signer's [DS] introduction of new semantics for the NXT RR that are
+ incompatible with the semantics in RFC 2535 [RFC2535]. Answers
+ provided by DS-aware servers can trigger an unacceptable failure
+ mode in some resolvers that implement RFC 2535, which provides a
+ great disincentive to sign zones with DS. The changes defined in
+ this document allow for the incremental deployment of DS.
+
+1.1 Terminology
+
+ In this document, the term "unsecure delegation" means any
+ delegation for which no DS record appears at the parent. An
+ "unsecure referral" is an answer from the parent containing an NS
+ RRset and a proof that no DS record exists for that name.
+
+ 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].
+
+1.2 The Problem
+
+ Delegation Signer introduces new semantics for the NXT RR that are
+ incompatible with the semantics in RFC 2535. In RFC 2535, NXT
+ records were only required to be returned as part of a
+ non-existence proof. With DS, an unsecure referral returns, in
+ addition to the NS, a proof of non-existence of a DS RR in the form
+ of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
+ to interpret a response with both an NS and an NXT in the authority
+ section, RCODE=0, and AA=0. Some widely deployed 2535-aware
+ resolvers interpret any answer with an NXT as a proof of
+ non-existence of the requested record. This results in unsecure
+ delegations being invisible to 2535-aware resolvers and violates
+ the basic architectural principle that DNSSEC must do no harm --
+ the signing of zones must not prevent the resolution of unsecured
+ delegations.
+
+2. Possible Solutions
+
+ This section presents several solutions that were considered.
+ Section 3 describes the one selected.
+
+2.1. Change SIG, KEY, and NXT type codes
+
+ To avoid the problem described above, legacy (RFC2535-aware)
+ resolvers need to be kept from seeing unsecure referrals that
+ include NXT records in the authority section. The simplest way to
+ do that is to change the type codes for SIG, KEY, and NXT.
+
+ The obvious drawback to this is that new resolvers will not be able
+ to validate zones signed with the old RRs. This problem already
+ exists, however, because of the changes made by DS, and resolvers
+ that understand the old RRs (and have compatibility issues with DS)
+ are far more prevalent than 2535-signed zones.
+
+2.2. Change a subset of type codes
+
+ The observed problem with unsecure referrals could be addressed by
+ changing only the NXT type code or another subset of the type codes
+ that includes NXT. This has the virtue of apparent simplicity, but
+ it risks introducing new problems or not going far enough. It's
+ quite possible that more incompatibilities exist between DS and
+ earlier semantics. Legacy resolvers may also be confused by seeing
+ records they recognize (SIG and KEY) while being unable to find
+ NXTs. Although it may seem unnecessary to fix that which is not
+ obviously broken, it's far cleaner to change all of the type codes
+ at once. This will leave legacy resolvers and tools completely
+ blinded to DNSSEC -- they will see only unknown RRs.
+
+2.3. Replace the DO bit
+
+ Another way to keep legacy resolvers from ever seeing DNSSEC
+ records with DS semantics is to have authoritative servers only
+ send that data to DS-aware resolvers. It's been proposed that
+ assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
+ called "DA"), and having authoritative servers send DNSSEC data
+ only in response to queries with the DA bit set, would accomplish
+ this. This bit would presumably supplant the DO bit described in
+ RFC 3225.
+
+ This solution is sufficient only if all 2535-aware resolvers zero
+ out EDNS0 flags that they don't understand. If one passed through
+ the DA bit unchanged, it would still see the new semantics, and it
+ would probably fail to see unsecure delegations. Since it's
+ impractical to know how every DNS implementation handles unknown
+ EDNS0 flags, this is not a universal solution. It could, though,
+ be considered in addition to changing the RR type codes.
+
+2.4. Increment the EDNS version
+
+ Another possible solution is to increment the EDNS version number
+ as defined in RFC 2671 [RFC2671], on the assumption that all
+ existing implementations will reject higher versions than they
+ support, and retain the DO bit as the signal for DNSSEC awareness.
+ This approach has not been tested.
+
+2.5. Do nothing
+
+ There is a large deployed base of DNS resolvers that understand
+ DNSSEC as defined by the standards track RFC 2535 and RFC 2065
+ and, due to under specification in those documents, interpret any
+ answer with an NXT as a non-existence proof. So long as that is
+ the case, zone owners will have a strong incentive to not sign any
+ zones that contain unsecure delegations, lest those delegations be
+ invisible to such a large installed base. This will dramatically
+ slow DNSSEC adoption.
+
+ Unfortunately, without signed zones there's no clear incentive for
+ operators of resolvers to upgrade their software to support the new
+ version of DNSSEC, as defined in [DS]. Historical data suggests
+ that resolvers are rarely upgraded, and that old nameserver code
+ never dies.
+
+ Rather than wait years for resolvers to be upgraded through natural
+ processes before signing zones with unsecure delegations,
+ addressing this problem with a protocol change will immediately
+ remove the disincentive for signing zones and allow widespread
+ deployment of DNSSEC.
+
+3. Protocol changes
+
+ This document changes the type codes of SIG, KEY, and NXT. This
+ approach is the cleanest and safest of those discussed above,
+ largely because the behavior of resolvers that receive unknown type
+ codes is well understood. This approach has also received the most
+ testing.
+
+ To avoid operational confusion, it's also necessary to change the
+ mnemonics for these RRs. DNSKEY will be the replacement for KEY,
+ with the mnemonic indicating that these keys are not for
+ application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
+ will replace SIG, and NSEC (Next SECure) will replace NXT. These
+ new types completely replace the old types, except that SIG(0)
+ [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
+
+ The new types will have exactly the same syntax and semantics as
+ specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
+ the following:
+
+ 1) Consistent with [RFC3597], domain names embedded in
+ RRSIG and NSEC RRs MUST NOT be compressed,
+
+ 2) Embedded domain names in RRSIG and NSEC RRs are not downcased
+ for purposes of DNSSEC canonical form and ordering nor for
+ equality comparison, and
+
+ 3) An RRSIG with a type-covered field of zero has undefined
+ semantics. The meaning of such a resource record may only be
+ defined by IETF Standards Action.
+
+ If a resolver receives the old types, it SHOULD treat them as
+ unknown RRs and SHOULD NOT assign any special meaning to them or
+ give them any special treatment. It MUST NOT use them for DNSSEC
+ validations or other DNS operational decision making. For example,
+ a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
+ validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone,
+ they MUST NOT receive special treatment. As an example, if a SIG
+ is included in a signed zone, there MUST be an RRSIG for it.
+ Authoritative servers may wish to give error messages when loading
+ zones containing SIG or NXT records (KEY records may be included
+ for SIG(0) or TKEY).
+
+ As a clarification to previous documents, some positive responses,
+ particularly wildcard proofs and unsecure referrals, will contain
+ NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as
+ negative answers merely because they contain an NSEC.
+
+4. IANA Considerations
+
+4.1 DNS Resource Record Types
+
+ This document updates the IANA registry for DNS Resource Record
+ Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
+ DNSKEY RRs, respectively.
+
+ Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
+ TKEY [RFC2930] use only.
+
+ Type 30 (NXT) should be marked as Obsolete.
+
+4.2 DNS Security Algorithm Numbers
+
+ To allow zone signing (DNSSEC) and transaction security mechanisms
+ (SIG(0) and TKEY) to use different sets of algorithms, the existing
+ "DNS Security Algorithm Numbers" registry is modified to include
+ the applicability of each algorithm. Specifically, two new columns
+ are added to the registry, showing whether each algorithm may be
+ used for zone signing, transaction security mechanisms, or both.
+ Only algorithms usable for zone signing may be used in DNSKEY,
+ RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG
+ may be used in SIG and KEY RRs.
+
+ All currently defined algorithms remain usable for transaction
+ security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private
+ algorithms (types 253 and 254) may be used for zone signing. Note
+ that the registry does not contain the requirement level of each
+ algorithm, only whether or not an algorithm may be used for the
+ given purposes. For example, RSA/MD5, while allowed for
+ transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
+
+ Additionally, the presentation format algorithm mnemonics from
+ RFC2535 Section 7 are added to the registry. This document assigns
+ RSA/SHA-1 the mnemonic RSASHA1.
+
+ As before, assignment of new algorithms in this registry requires
+ IETF Standards Action. Additionally, modification of algorithm
+ mnemonics or applicability requires IETF Standards Action.
+ Documents defining a new algorithm must address the applicability
+ of the algorithm and should assign a presentation mnemonic to the
+ algorithm.
+
+4.3 DNSKEY Flags
+
+ Like the KEY resource record, DNSKEY contains a 16-bit flags field.
+ This document creates a new registry for the DNSKEY flags field.
+
+ Initially, this registry only contains an assignment for bit 7 (the
+ ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
+ Standards Action.
+
+4.4 DNSKEY Protocol Octet
+
+ Like the KEY resource record, DNSKEY contains an eight bit protocol
+ field. The only defined value for this field is 3 (DNSSEC). No
+ other values are allowed, hence no IANA registry is needed for this
+ field.
+
+5. Security Considerations
+
+ The changes introduced here do not materially affect security.
+ The implications of trying to use both new and legacy types
+ together are not well understood, and attempts to do so would
+ probably lead to unintended and dangerous results.
+
+ Changing type codes will leave code paths in legacy resolvers that
+ are never exercised. Unexercised code paths are a frequent source
+ of security holes, largely because those code paths do not get
+ frequent scrutiny.
+
+ Doing nothing, as described in section 2.5, will slow DNSSEC
+ deployment. While this does not decrease security, it also fails
+ to increase it.
+
+6. Normative references
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [DS] Gudmundsson, O., "Delegation Signer Resource Record",
+ draft-ietf-dnsext-delegation-signer-15.txt, work in
+ progress, June 2003.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+ (SIG(0)s)", RFC 2931, September 2000.
+
+ [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
+ RR)", RFC 2930, September 2000.
+
+ [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
+ System (DNS)", RFC 2436, March 1999.
+
+ [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
+ Domain Name System (DNS)", RFC 2539, March 1999.
+
+ [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+ Domain Name System (DNS)", RFC 3110, May 2001.
+
+7. Informative References
+
+ [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
+ Extensions", RFC 2065, January 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+ 3225, December 2001.
+
+ [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
+ "Domain Name System (DNS) IANA Considerations", BCP 42,
+ RFC 2929, September 2000.
+
+ [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
+ Resource Record (RR)", RFC 3445, December 2002.
+
+ [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
+ Record (RR) Types", RFC 3597, September 2003.
+
+8. Acknowledgments
+
+ The changes introduced here and the analysis of alternatives had
+ many contributors. With apologies to anyone overlooked, those
+ include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
+ Lewis, Bill Manning, and Suzanne Woolf.
+
+ Thanks to Jakob Schlyter and Mark Andrews for identifying the
+ incompatibility described in section 1.2.
+
+ In addition to the above, the author would like to thank Scott
+ Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
+ comments.
+
+9. Author's Address
+
+ Samuel Weiler
+ SPARTA, Inc.
+ 7075 Samuel Morse Drive
+ Columbia, MD 21046
+ USA
+ weiler@tislabs.com
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
new file mode 100644
index 0000000..3a800f9
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
@@ -0,0 +1,616 @@
+
+
+
+Network Working Group S. Weiler
+Internet-Draft SPARTA, Inc
+Updates: 4034, 4035 (if approved) May 23, 2005
+Expires: November 24, 2005
+
+
+ Clarifications and Implementation Notes for DNSSECbis
+ draft-ietf-dnsext-dnssec-bis-updates-01
+
+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 November 24, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document is a collection of minor technical clarifications to
+ the DNSSECbis document set. It is meant to serve as a resource to
+ implementors as well as an interim repository of possible DNSSECbis
+ errata.
+
+
+
+
+
+
+
+Weiler Expires November 24, 2005 [Page 1]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+Proposed additions in future versions
+
+ An index sorted by the section of DNSSECbis being clarified.
+
+ A list of proposed protocol changes being made in other documents,
+ such as NSEC3 and Epsilon. This document would not make those
+ changes, merely provide an index into the documents that are making
+ changes.
+
+Changes between -00 and -01
+
+ Document significantly restructured.
+
+ Added section on QTYPE=ANY.
+
+Changes between personal submission and first WG draft
+
+ Added Section 2.1 based on namedroppers discussions from March 9-10,
+ 2005.
+
+ Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
+
+ Added the DNSSECbis RFC numbers.
+
+ Figured out the confusion in Section 4.1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler Expires November 24, 2005 [Page 2]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+Table of Contents
+
+ 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
+ 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4
+ 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4
+ 2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5
+ 2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5
+ 3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
+ 3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
+ 3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
+ 3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6
+ 3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
+ 4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7
+ 4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7
+ 4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7
+ 4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
+ 7.2 Informative References . . . . . . . . . . . . . . . . . . 9
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
+ A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
+ Intellectual Property and Copyright Statements . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler Expires November 24, 2005 [Page 3]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+1. Introduction and Terminology
+
+ This document lists some minor clarifications and corrections to
+ DNSSECbis, as described in [1], [2], and [3].
+
+ It is intended to serve as a resource for implementors and as a
+ repository of items that need to be addressed when advancing the
+ DNSSECbis documents from Proposed Standard to Draft Standard.
+
+ In this version (-01 of the WG document), feedback is particularly
+ solicited on the structure of the document and whether the text in
+ the recently added sections is correct and sufficient.
+
+ Proposed substantive additions to this document should be sent to the
+ namedroppers mailing list as well as to the editor of this document.
+ The editor would greatly prefer text suitable for direct inclusion in
+ this document.
+
+1.1 Structure of this Document
+
+ The clarifications to DNSSECbis are sorted according to the editor's
+ impression of their importance, starting with ones which could, if
+ ignored, lead to security and stability problems and progressing down
+ to clarifications that are likely to have little operational impact.
+ Mere typos and awkward phrasings are not addressed unless they could
+ lead to misinterpretation of the DNSSECbis documents.
+
+1.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 RFC 2119 [4].
+
+2. Significant Concerns
+
+ This section provides clarifications that, if overlooked, could lead
+ to security issues or major interoperability problems.
+
+2.1 Clarifications on Non-Existence Proofs
+
+ RFC4035 Section 5.4 slightly underspecifies the algorithm for
+ checking non-existence proofs. In particular, the algorithm there
+ might incorrectly allow the NSEC from the parent side of a zone cut
+ to prove the non-existence of either other RRs at that name in the
+ child zone or other names in the child zone. It might also allow a
+ NSEC at the same name as a DNAME to prove the non-existence of names
+ beneath that DNAME.
+
+
+
+
+Weiler Expires November 24, 2005 [Page 4]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+ A parent-side delegation NSEC (one with the NS bit set, but no SOA
+ bit set, and with a singer field that's shorter than the owner name)
+ must not be used to assume non-existence of any RRs below that zone
+ cut (both RRs at that ownername and at ownernames with more leading
+ labels, no matter their content). Similarly, an NSEC with the DNAME
+ bit set must not be used to assume the non-existence of any
+ descendant of that NSEC's owner name.
+
+2.2 Empty Non-Terminal Proofs
+
+ To be written, based on Roy Arends' May 11th message to namedroppers.
+
+2.3 Validating Responses to an ANY Query
+
+ RFC4035 does not address now to validate responses when QTYPE=*. As
+ described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
+ may include a subset of the RRsets at a given name -- it is not
+ necessary to include all RRsets at the QNAME in the response.
+
+ When validating a response to QTYPE=*, validate all received RRsets
+ that match QNAME and QCLASS. If any of those RRsets fail validation,
+ treat the answer as Bogus. If there are no RRsets matching QNAME and
+ QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
+ clarified in this document). To be clear, a validator must not
+ insist on receiving all records at the QNAME in response to QTYPE=*.
+
+3. Interoperability Concerns
+
+3.1 Unknown DS Message Digest Algorithms
+
+ Section 5.2 of RFC4035 includes rules for how to handle delegations
+ to zones that are signed with entirely unsupported algorithms, as
+ indicated by the algorithms shown in those zone's DS RRsets. It does
+ not explicitly address how to handle DS records that use unsupported
+ message digest algorithms. In brief, DS records using unknown or
+ unsupported message digest algorithms MUST be treated the same way as
+ DS records referring to DNSKEY RRs of unknown or unsupported
+ algorithms.
+
+ The existing text says:
+
+ 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.
+
+
+
+
+Weiler Expires November 24, 2005 [Page 5]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+ To paraphrase the above, when determining the security status of a
+ zone, a validator discards (for this purpose only) any DS records
+ listing unknown or unsupported algorithms. If none are left, the
+ zone is treated as if it were unsigned.
+
+ Modified to consider DS message digest algorithms, a validator also
+ discards any DS records using unknown or unsupported message digest
+ algorithms.
+
+3.2 Private Algorithms
+
+ As discussed above, section 5.2 of RFC4035 requires that validators
+ make decisions about the security status of zones based on the public
+ key algorithms shown in the DS records for those zones. In the case
+ of private algorithms, as described in RFC4034 Appendix A.1.1, the
+ eight-bit algorithm field in the DS RR is not conclusive about what
+ algorithm(s) is actually in use.
+
+ If no private algorithms appear in the DS set or if any supported
+ algorithm appears in the DS set, no special processing will be
+ needed. In the remaining cases, the security status of the zone
+ depends on whether or not the resolver supports any of the private
+ algorithms in use (provided that these DS records use supported hash
+ functions, as discussed in Section 3.1). In these cases, the
+ resolver MUST retrieve the corresponding DNSKEY for each private
+ algorithm DS record and examine the public key field to determine the
+ algorithm in use. The security-aware resolver MUST ensure that the
+ hash of the DNSKEY RR's owner name and RDATA matches the digest in
+ the DS RR. If they do not match, and no other DS establishes that
+ the zone is secure, the referral should be considered BAD data, as
+ discussed in RFC4035.
+
+ This clarification facilitates the broader use of private algorithms,
+ as suggested by [5].
+
+3.3 Caution About Local Policy and Multiple RRSIGs
+
+ When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
+ suggests that "the local resolver security policy determines whether
+ the resolver also has to test these RRSIG RRs and how to resolve
+ conflicts if these RRSIG RRs lead to differing results." In most
+ cases, a resolver would be well advised to accept any valid RRSIG as
+ sufficient. If the first RRSIG tested fails validation, a resolver
+ would be well advised to try others, giving a successful validation
+ result if any can be validated and giving a failure only if all
+ RRSIGs fail validation.
+
+ If a resolver adopts a more restrictive policy, there's a danger that
+
+
+
+Weiler Expires November 24, 2005 [Page 6]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+ properly-signed data might unnecessarily fail validation, perhaps
+ because of cache timing issues. Furthermore, certain zone management
+ techniques, like the Double Signature Zone-signing Key Rollover
+ method described in section 4.2.1.2 of [6] might not work reliably.
+
+3.4 Key Tag Calculation
+
+ RFC4034 Appendix B.1 incorrectly defines the Key Tag field
+ calculation for algorithm 1. It correctly says that the Key Tag is
+ the most significant 16 of the least significant 24 bits of the
+ public key modulus. However, RFC4034 then goes on to incorrectly say
+ that this is 4th to last and 3rd to last octets of the public key
+ modulus. It is, in fact, the 3rd to last and 2nd to last octets.
+
+4. Minor Corrections and Clarifications
+
+4.1 Finding Zone Cuts
+
+ Appendix C.8 of RFC4035 discusses sending DS queries to the servers
+ for a parent zone. To do that, a resolver may first need to apply
+ special rules to discover what those servers are.
+
+ As explained in Section 3.1.4.1 of RFC4035, security-aware name
+ servers need to apply special processing rules to handle the DS RR,
+ and in some situations the resolver may also need to apply special
+ rules to locate the name servers for the parent zone if the resolver
+ does not already have the parent's NS RRset. Section 4.2 of RFC4035
+ specifies a mechanism for doing that.
+
+4.2 Clarifications on DNSKEY Usage
+
+ Questions of the form "can I use a different DNSKEY for signing the
+ X" have occasionally arisen.
+
+ The short answer is "yes, absolutely". You can even use a different
+ DNSKEY for each RRset in a zone, subject only to practical limits on
+ the size of the DNSKEY RRset. However, be aware that there is no way
+ to tell resolvers what a particularly DNSKEY is supposed to be used
+ for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
+ authenticate any RRset in the zone. For example, if a weaker or less
+ trusted DNSKEY is being used to authenticate NSEC RRsets or all
+ dynamically updated records, that same DNSKEY can also be used to
+ sign any other RRsets from the zone.
+
+ Furthermore, note that the SEP bit setting has no effect on how a
+ DNSKEY may be used -- the validation process is specifically
+ prohibited from using that bit by RFC4034 section 2.1.2. It possible
+ to use a DNSKEY without the SEP bit set as the sole secure entry
+
+
+
+Weiler Expires November 24, 2005 [Page 7]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+ point to the zone, yet use a DNSKEY with the SEP bit set to sign all
+ RRsets in the zone (other than the DNSKEY RRset). It's also possible
+ to use a single DNSKEY, with or without the SEP bit set, to sign the
+ entire zone, including the DNSKEY RRset itself.
+
+4.3 Errors in Examples
+
+ The text in RFC4035 Section C.1 refers to the examples in B.1 as
+ "x.w.example.com" while B.1 uses "x.w.example". This is painfully
+ obvious in the second paragraph where it states that the RRSIG labels
+ field value of 3 indicates that the answer was not the result of
+ wildcard expansion. This is true for "x.w.example" but not for
+ "x.w.example.com", which of course has a label count of 4
+ (antithetically, a label count of 3 would imply the answer was the
+ result of a wildcard expansion).
+
+ The first paragraph of RFC4035 Section C.6 also has a minor error:
+ the reference to "a.z.w.w.example" should instead be "a.z.w.example",
+ as in the previous line.
+
+5. IANA Considerations
+
+ This document specifies no IANA Actions.
+
+6. Security Considerations
+
+ This document does not make fundamental changes to the DNSSEC
+ protocol, as it was generally understood when DNSSECbis was
+ published. It does, however, address some ambiguities and omissions
+ in those documents that, if not recognized and addressed in
+ implementations, could lead to security failures. In particular, the
+ validation algorithm clarifications in Section 2 are critical for
+ preserving the security properties DNSSEC offers. Furthermore,
+ failure to address some of the interoperability concerns in Section 3
+ could limit the ability to later change or expand DNSSEC, including
+ by adding new algorithms.
+
+7. References
+
+7.1 Normative References
+
+ [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+
+
+Weiler Expires November 24, 2005 [Page 8]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+ [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+7.2 Informative References
+
+ [5] Blacka, D., "DNSSEC Experiments",
+ draft-blacka-dnssec-experiments-00 (work in progress),
+ December 2004.
+
+ [6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
+ draft-ietf-dnsop-dnssec-operational-practices-04 (work in
+ progress), May 2005.
+
+
+Author's Address
+
+ Samuel Weiler
+ SPARTA, Inc
+ 7075 Samuel Morse Drive
+ Columbia, Maryland 21046
+ US
+
+ Email: weiler@tislabs.com
+
+Appendix A. Acknowledgments
+
+ The editor is extremely grateful to those who, in addition to finding
+ errors and omissions in the DNSSECbis document set, have provided
+ text suitable for inclusion in this document.
+
+ The lack of specificity about handling private algorithms, as
+ described in Section 3.2, and the lack of specificity in handling ANY
+ queries, as described in Section 2.3, were discovered by David
+ Blacka.
+
+ The error in algorithm 1 key tag calculation, as described in
+ Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake
+ contributed text for Section 3.4.
+
+ The bug relating to delegation NSEC RR's in Section 2.1 was found by
+ Roy Badami. Roy Arends found the related problem with DNAME.
+
+ The errors in the RFC4035 examples were found by Roy Arends, who also
+ contributed text for Section 4.3 of this document.
+
+
+
+Weiler Expires November 24, 2005 [Page 9]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+ The editor would like to thank Olafur Gudmundsson and Scott Rose for
+ their substantive comments on the text of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler Expires November 24, 2005 [Page 10]
+
+Internet-Draft DNSSECbis Implementation Notes May 2005
+
+
+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 (2005). 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.
+
+
+
+
+Weiler Expires November 24, 2005 [Page 11]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
new file mode 100644
index 0000000..ee03583
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
@@ -0,0 +1,784 @@
+
+
+
+DNSEXT D. Blacka
+Internet-Draft Verisign, Inc.
+Expires: January 19, 2006 July 18, 2005
+
+
+ DNSSEC Experiments
+ draft-ietf-dnsext-dnssec-experiments-01
+
+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 January 19, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ In the long history of the development of the DNS security extensions
+ [1] (DNSSEC), a number of alternate methodologies and modifications
+ have been proposed and rejected for practical, rather than strictly
+ technical, reasons. There is a desire to be able to experiment with
+ these alternate methods in the public DNS. This document describes a
+ methodology for deploying alternate, non-backwards-compatible, DNSSEC
+ methodologies in an experimental fashion without disrupting the
+ deployment of standard DNSSEC.
+
+
+
+
+Blacka Expires January 19, 2006 [Page 1]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+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. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 13
+ Intellectual Property and Copyright Statements . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires January 19, 2006 [Page 2]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+1. Definitions and Terminology
+
+ Throughout this document, familiarity with the DNS system (RFC 1035
+ [4]) and the DNS security extensions ([1], [2], and [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 [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires January 19, 2006 [Page 3]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+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 DNSSEC-aware resolvers.
+
+ This document describes a standard methodology for setting up public
+ 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 DNSSEC-aware resolvers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires January 19, 2006 [Page 4]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+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 server that do implement the DNSSEC
+ standard.
+
+ Non-Backwards-Compatible: describes experiments that would cause a
+ standard DNSSEC-aware resolver to (incorrectly) determine that all
+ or part of a zone is bogus, or to otherwise not interoperable 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 could be used
+ if desired.
+
+ Note that, in essence, this metholodolgy would also be used to
+ introduce a new DNSSEC algorithm, independently from any DNSSEC
+ experimental protocol change.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires January 19, 2006 [Page 5]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+4. Method
+
+ The core of the methodology is the use of strictly "unknown"
+ algorithms to sign the experimental zone, and more importantly,
+ having only unknown algorithm 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
+ algorithms. From [3], 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 unlikely that a validator would not implement the behavior, or,
+ more to the point, it will not violate this behavior in an unsafe way
+ (see below (Section 6).)
+
+ Because we are talking about experiments, it is RECOMMENDED that
+ private algorithm numbers be used (see [2], appendix A.1.1. Note
+ that secure handling of private algorithms requires special handing
+ by the validator logic. See [6] for futher 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 RECOMMENDED 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 will
+
+
+
+Blacka Expires January 19, 2006 [Page 6]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+ suffice.
+
+ Using this method, resolvers (or, more specificially, 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 DNSSEC-aware servers and
+ resolvers: servers and resolvers that are aware of the experiment
+ (and thus recognize the experiments algorithm identifiers and
+ experimental semantics), and servers and resolvers that are unware 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
+ isn't.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires January 19, 2006 [Page 7]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+5. Defining an Experiment
+
+ The DNSSEC experiment must define the particular set of (previously
+ unknown) algorithms 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 (see below (Section 9).)
+
+ For example, an experiment might specify in its description the DNS
+ name "dnssec-experiment-a.example.com" as the base name, and provide
+ the mapping of "3.dnssec-experiment-a.example.com" is an alias of
+ DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
+ an alias of DNSSEC algorithm 5 (RSASHA1).
+
+ Resolvers MUST then only recognize the experiment's semantics when
+ present in a zone signed by one or more of these private algorithms.
+
+ In general, however, 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 January 19, 2006 [Page 8]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+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 the not validatable response and
+ conclude that the response is bogus, either due to local policy
+ or implementation details. This is not expected to be the common
+ case, however.
+
+ 2. In general, it will not be possible for DNSSEC-aware resolvers
+ not aware of the experiment to build a chain of trust through an
+ experimental zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires January 19, 2006 [Page 9]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+7. Transitions
+
+ If an experiment is successful, there may be a desire to move the
+ experiment to a standards-track extension. One way to do so would be
+ to move from private algorithm numbers to IANA allocated algorithm
+ numbers, with otherwise the same meaning. This would still leave a
+ divide between resolvers that understood the extension versus
+ resolvers that did not. It would, in essence, create an additional
+ version of DNSSEC.
+
+ An alternate technique might be to do a typecode rollover, thus
+ actually creating a definitive new version of DNSSEC. There may be
+ other transition techniques available, as well.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires January 19, 2006 [Page 10]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+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 January 19, 2006 [Page 11]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+9. IANA Considerations
+
+ IANA may need to allocate new DNSSEC algorithm numbers if that
+ transition approach is taken, or the experiment decides to use
+ allocated numbers to begin with. No IANA action is required to
+ deploy an experiment using private algorithm identifiers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blacka Expires January 19, 2006 [Page 12]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+10. References
+
+10.1 Normative References
+
+ [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [3] 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
+
+ [4] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [6] Weiler, S., "Clarifications and Implementation Notes for
+ DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
+ progress), March 2005.
+
+
+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 January 19, 2006 [Page 13]
+
+Internet-Draft DNSSEC Experiments July 2005
+
+
+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 (2005). 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.
+
+
+
+
+Blacka Expires January 19, 2006 [Page 14]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
new file mode 100644
index 0000000..7503c66
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
@@ -0,0 +1,616 @@
+
+
+
+Network Working Group S. Weiler
+Internet-Draft SPARTA, Inc
+Updates: 4034, 4035 (if approved) J. Ihren
+Expires: July 24, 2006 Autonomica AB
+ January 20, 2006
+
+
+ Minimally Covering NSEC Records and DNSSEC On-line Signing
+ draft-ietf-dnsext-dnssec-online-signing-02
+
+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 July 24, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes how to construct DNSSEC NSEC resource records
+ that cover a smaller range of names than called for by RFC4034. By
+ generating and signing these records on demand, authoritative name
+ servers can effectively stop the disclosure of zone contents
+ otherwise made possible by walking the chain of NSEC records in a
+ signed zone.
+
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 1]
+
+Internet-Draft NSEC Epsilon January 2006
+
+
+Changes from ietf-01 to ietf-02
+
+ Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
+ and NSEC bits set, to be consistent with DNSSECbis -- previous text
+ said SHOULD.
+
+ Made the applicability statement a little less oppressive.
+
+Changes from ietf-00 to ietf-01
+
+ Added an applicability statement, making reference to ongoing work on
+ NSEC3.
+
+ Added the phrase "epsilon functions", which has been commonly used to
+ describe the technique and already appeared in the header of each
+ page, in place of "increment and decrement functions". Also added an
+ explanatory sentence.
+
+ Corrected references from 4034 section 6.2 to section 6.1.
+
+ Fixed an out-of-date reference to [-bis] and other typos.
+
+ Replaced IANA Considerations text.
+
+ Escaped close parentheses in examples.
+
+ Added some more acknowledgements.
+
+Changes from weiler-01 to ietf-00
+
+ Inserted RFC numbers for 4033, 4034, and 4035.
+
+ Specified contents of bitmap field in synthesized NSEC RR's, pointing
+ out that this relaxes a constraint in 4035. Added 4035 to the
+ Updates header.
+
+Changes from weiler-00 to weiler-01
+
+ Clarified that this updates RFC4034 by relaxing requirements on the
+ next name field.
+
+ Added examples covering wildcard names.
+
+ In the 'better functions' section, reiterated that perfect functions
+ aren't needed.
+
+ Added a reference to RFC 2119.
+
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 2]
+
+Internet-Draft NSEC Epsilon January 2006
+
+
+Table of Contents
+
+ 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
+ 2. Applicability of This Technique . . . . . . . . . . . . . . . 4
+ 3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5
+ 4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
+ 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
+ Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
+ Intellectual Property and Copyright Statements . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 3]
+
+Internet-Draft NSEC Epsilon January 2006
+
+
+1. Introduction and Terminology
+
+ With DNSSEC [1], an NSEC record lists the next instantiated name in
+ its zone, proving that no names exist in the "span" between the
+ NSEC's owner name and the name in the "next name" field. In this
+ document, an NSEC record is said to "cover" the names between its
+ owner name and next name.
+
+ Through repeated queries that return NSEC records, it is possible to
+ retrieve all of the names in the zone, a process commonly called
+ "walking" the zone. Some zone owners have policies forbidding zone
+ transfers by arbitrary clients; this side-effect of the NSEC
+ architecture subverts those policies.
+
+ This document presents a way to prevent zone walking by constructing
+ NSEC records that cover fewer names. These records can make zone
+ walking take approximately as many queries as simply asking for all
+ possible names in a zone, making zone walking impractical. Some of
+ these records must be created and signed on demand, which requires
+ on-line private keys. Anyone contemplating use of this technique is
+ strongly encouraged to review the discussion of the risks of on-line
+ signing in Section 6.
+
+ 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 [4].
+
+
+2. Applicability of This Technique
+
+ The technique presented here may be useful to a zone owner that wants
+ to use DNSSEC, is concerned about exposure of its zone contents via
+ zone walking, and is willing to bear the costs of on-line signing.
+
+ As discussed in Section 6, on-line signing has several security
+ risks, including an increased likelihood of private keys being
+ disclosed and an increased risk of denial of service attack. Anyone
+ contemplating use of this technique is strongly encouraged to review
+ the discussion of the risks of on-line signing in Section 6.
+
+ Furthermore, at the time this document was published, the DNSEXT
+ working group was actively working on a mechanism to prevent zone
+ walking that does not require on-line signing (tentatively called
+ NSEC3). The new mechanism is likely to expose slightly more
+ information about the zone than this technique (e.g. the number of
+ instantiated names), but it may be preferable to this technique.
+
+
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 4]
+
+Internet-Draft NSEC Epsilon January 2006
+
+
+3. Minimally Covering NSEC Records
+
+ This mechanism involves changes to NSEC records for instantiated
+ names, which can still be generated and signed in advance, as well as
+ the on-demand generation and signing of new NSEC records whenever a
+ name must be proven not to exist.
+
+ In the 'next name' field of instantiated names' NSEC records, rather
+ than list the next instantiated name in the zone, list any name that
+ falls lexically after the NSEC's owner name and before the next
+ instantiated name in the zone, according to the ordering function in
+ RFC4034 [2] section 6.1. This relaxes the requirement in section
+ 4.1.1 of RFC4034 that the 'next name' field contains the next owner
+ name in the zone. This change is expected to be fully compatible
+ with all existing DNSSEC validators. These NSEC records are returned
+ whenever proving something specifically about the owner name (e.g.
+ that no resource records of a given type appear at that name).
+
+ Whenever an NSEC record is needed to prove the non-existence of a
+ name, a new NSEC record is dynamically produced and signed. The new
+ NSEC record has an owner name lexically before the QNAME but
+ lexically following any existing name and a 'next name' lexically
+ following the QNAME but before any existing name.
+
+ The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
+ bits set and SHOULD NOT have any other bits set. This relaxes the
+ requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
+ names that did not exist before the zone was signed.
+
+ The functions to generate the lexically following and proceeding
+ names need not be perfect nor consistent, but the generated NSEC
+ records must not cover any existing names. Furthermore, this
+ technique works best when the generated NSEC records cover as few
+ names as possible. In this document, the functions that generate the
+ nearby names are called 'epsilon' functions, a reference to the
+ mathematical convention of using the greek letter epsilon to
+ represent small deviations.
+
+ An NSEC record denying the existence of a wildcard may be generated
+ in the same way. Since the NSEC record covering a non-existent
+ wildcard is likely to be used in response to many queries,
+ authoritative name servers using the techniques described here may
+ want to pregenerate or cache that record and its corresponding RRSIG.
+
+ For example, a query for an A record at the non-instantiated name
+ example.com might produce the following two NSEC records, the first
+ denying the existence of the name example.com and the second denying
+ the existence of a wildcard:
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 5]
+
+Internet-Draft NSEC Epsilon January 2006
+
+
+ exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
+
+ \).com 3600 IN NSEC +.com ( RRSIG NSEC )
+
+ Before answering a query with these records, an authoritative server
+ must test for the existence of names between these endpoints. If the
+ generated NSEC would cover existing names (e.g. exampldd.com or
+ *bizarre.example.com), a better epsilon function may be used or the
+ covered name closest to the QNAME could be used as the NSEC owner
+ name or next name, as appropriate. If an existing name is used as
+ the NSEC owner name, that name's real NSEC record MUST be returned.
+ Using the same example, assuming an exampldd.com delegation exists,
+ this record might be returned from the parent:
+
+ exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
+
+ Like every authoritative record in the zone, each generated NSEC
+ record MUST have corresponding RRSIGs generated using each algorithm
+ (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
+ described in RFC4035 [3] section 2.2. To minimize the number of
+ signatures that must be generated, a zone may wish to limit the
+ number of algorithms in its DNSKEY RRset.
+
+
+4. Better Epsilon Functions
+
+ Section 6.1 of RFC4034 defines a strict ordering of DNS names.
+ Working backwards from that definition, it should be possible to
+ define epsilon functions that generate the immediately following and
+ preceding names, respectively. This document does not define such
+ functions. Instead, this section presents functions that come
+ reasonably close to the perfect ones. As described above, an
+ authoritative server should still ensure than no generated NSEC
+ covers any existing name.
+
+ To increment a name, add a leading label with a single null (zero-
+ value) octet.
+
+ To decrement a name, decrement the last character of the leftmost
+ label, then fill that label to a length of 63 octets with octets of
+ value 255. To decrement a null (zero-value) octet, remove the octet
+ -- if an empty label is left, remove the label. Defining this
+ function numerically: fill the left-most label to its maximum length
+ with zeros (numeric, not ASCII zeros) and subtract one.
+
+ In response to a query for the non-existent name foo.example.com,
+ these functions produce NSEC records of:
+
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 6]
+
+Internet-Draft NSEC Epsilon January 2006
+
+
+ fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+ \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
+
+ \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+ \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
+
+ The first of these NSEC RRs proves that no exact match for
+ foo.example.com exists, and the second proves that there is no
+ wildcard in example.com.
+
+ Both of these functions are imperfect: they don't take into account
+ constraints on number of labels in a name nor total length of a name.
+ As noted in the previous section, though, this technique does not
+ depend on the use of perfect epsilon functions: it is sufficient to
+ test whether any instantiated names fall into the span covered by the
+ generated NSEC and, if so, substitute those instantiated owner names
+ for the NSEC owner name or next name, as appropriate.
+
+
+5. IANA Considerations
+
+ This document specifies no IANA Actions.
+
+
+6. Security Considerations
+
+ This approach requires on-demand generation of RRSIG records. This
+ creates several new vulnerabilities.
+
+ First, on-demand signing requires that a zone's authoritative servers
+ have access to its private keys. Storing private keys on well-known
+ internet-accessible servers may make them more vulnerable to
+ unintended disclosure.
+
+ Second, since generation of digital signatures tends to be
+ computationally demanding, the requirement for on-demand signing
+ makes authoritative servers vulnerable to a denial of service attack.
+
+ Lastly, if the epsilon functions are predictable, on-demand signing
+ may enable a chosen-plaintext attack on a zone's private keys. Zones
+ using this approach should attempt to use cryptographic algorithms
+ that are resistant to chosen-plaintext attacks. It's worth noting
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 7]
+
+Internet-Draft NSEC Epsilon January 2006
+
+
+ that while DNSSEC has a "mandatory to implement" algorithm, that is a
+ requirement on resolvers and validators -- there is no requirement
+ that a zone be signed with any given algorithm.
+
+ The success of using minimally covering NSEC record to prevent zone
+ walking depends greatly on the quality of the epsilon functions
+ chosen. An increment function that chooses a name obviously derived
+ from the next instantiated name may be easily reverse engineered,
+ destroying the value of this technique. An increment function that
+ always returns a name close to the next instantiated name is likewise
+ a poor choice. Good choices of epsilon functions are the ones that
+ produce the immediately following and preceding names, respectively,
+ though zone administrators may wish to use less perfect functions
+ that return more human-friendly names than the functions described in
+ Section 4 above.
+
+ Another obvious but misguided concern is the danger from synthesized
+ NSEC records being replayed. It's possible for an attacker to replay
+ an old but still validly signed NSEC record after a new name has been
+ added in the span covered by that NSEC, incorrectly proving that
+ there is no record at that name. This danger exists with DNSSEC as
+ defined in [3]. The techniques described here actually decrease the
+ danger, since the span covered by any NSEC record is smaller than
+ before. Choosing better epsilon functions will further reduce this
+ danger.
+
+7. Normative References
+
+ [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+Appendix A. Acknowledgments
+
+ Many individuals contributed to this design. They include, in
+ addition to the authors of this document, Olaf Kolkman, Ed Lewis,
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 8]
+
+Internet-Draft NSEC Epsilon January 2006
+
+
+ Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
+ Jakob Schlyter, Bill Manning, and Joao Damas.
+
+ In addition, the editors would like to thank Ed Lewis, Scott Rose,
+ and David Blacka for their careful review of the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 9]
+
+Internet-Draft NSEC Epsilon January 2006
+
+
+Authors' Addresses
+
+ Samuel Weiler
+ SPARTA, Inc
+ 7075 Samuel Morse Drive
+ Columbia, Maryland 21046
+ US
+
+ Email: weiler@tislabs.com
+
+
+ Johan Ihren
+ Autonomica AB
+ Bellmansgatan 30
+ Stockholm SE-118 47
+ Sweden
+
+ Email: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 10]
+
+Internet-Draft NSEC Epsilon January 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.
+
+
+
+
+Weiler & Ihren Expires July 24, 2006 [Page 11]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
new file mode 100644
index 0000000..17e28e8
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
@@ -0,0 +1,896 @@
+
+
+
+DNSEXT R. Arends
+Internet-Draft Telematica Instituut
+Expires: January 19, 2006 M. Kosters
+ D. Blacka
+ Verisign, Inc.
+ July 18, 2005
+
+
+ DNSSEC Opt-In
+ draft-ietf-dnsext-dnssec-opt-in-07
+
+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 January 19, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
+ 4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
+ cryptographically secured. Maintaining this cryptography is not
+ practical or necessary. This document describes an experimental
+ "Opt-In" model that allows administrators to omit this cryptography
+ and manage the cost of adopting DNSSEC with large zones.
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 1]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+Table of Contents
+
+ 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
+ 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4
+ 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 5
+ 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 5
+ 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 6
+ 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 6
+ 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 7
+ 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 7
+ 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7
+ 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 7
+ 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 8
+ 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 8
+ 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
+ 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 11.1 Normative References . . . . . . . . . . . . . . . . . . . 13
+ 11.2 Informative References . . . . . . . . . . . . . . . . . . 13
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+ A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14
+ Intellectual Property and Copyright Statements . . . . . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 2]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+1. Definitions and Terminology
+
+ Throughout this document, familiarity with the DNS system (RFC 1035
+ [1]), DNS security extensions ([3], [4], and [5], referred to in this
+ document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
+ [10]) is assumed.
+
+ The following abbreviations and terms are used in this document:
+
+ RR: is used to refer to a DNS resource record.
+ RRset: refers to a Resource Record Set, as defined by [8]. In this
+ document, the RRset is also defined to include the covering RRSIG
+ records, if any exist.
+ signed name: refers to a DNS name that has, at minimum, a (signed)
+ NSEC record.
+ unsigned name: refers to a DNS name that does not (at least) have a
+ NSEC record.
+ covering NSEC record/RRset: is the NSEC record used to prove
+ (non)existence of a particular name or RRset. This means that for
+ a RRset or name 'N', the covering NSEC record has the name 'N', or
+ has an owner name less than 'N' and "next" name greater than 'N'.
+ delegation: refers to a NS RRset with a name different from the
+ current zone apex (non-zone-apex), signifying a delegation to a
+ subzone.
+ secure delegation: refers to a signed name containing a delegation
+ (NS RRset), and a signed DS RRset, signifying a delegation to a
+ signed subzone.
+ insecure delegation: refers to a signed name containing a delegation
+ (NS RRset), but lacking a DS RRset, signifying a delegation to an
+ unsigned subzone.
+ Opt-In insecure delegation: refers to an unsigned name containing
+ only a delegation NS RRset. The covering NSEC record uses the
+ Opt-In methodology described 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 RFC 2119 [7].
+
+2. Overview
+
+ The cost to cryptographically secure delegations to unsigned zones is
+ high for large delegation-centric zones and zones where insecure
+ delegations will be updated rapidly. For these zones, the costs of
+ maintaining the NSEC record chain may be extremely high relative to
+ the gain of cryptographically authenticating existence of unsecured
+ zones.
+
+ This document describes an experimental method of eliminating the
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 3]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ superfluous cryptography present in secure delegations to unsigned
+ zones. Using "Opt-In", a zone administrator can choose to remove
+ insecure delegations from the NSEC chain. This is accomplished by
+ extending the semantics of the NSEC record by using a redundant bit
+ in the type map.
+
+3. Experimental Status
+
+ This document describes an EXPERIMENTAL extension to DNSSEC. It
+ interoperates with non-experimental DNSSEC using the technique
+ described in [6]. This experiment is identified with the following
+ private algorithms (using algorithm 253):
+
+ "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
+ and
+ "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
+ RSASHA1.
+
+ Servers wishing to sign and serve zones that utilize Opt-In MUST sign
+ the zone with only one or more of these private algorithms. This
+ requires the signing tools and servers to support private algorithms,
+ as well as Opt-In.
+
+ Resolvers wishing to validate Opt-In zones MUST only do so when the
+ zone is only signed using one or more of these private algorithms.
+
+ The remainder of this document assumes that the servers and resolvers
+ involved are aware of and are involved in this experiment.
+
+4. Protocol Additions
+
+ In DNSSEC, delegation NS RRsets are not signed, but are instead
+ accompanied by a NSEC RRset of the same name and (possibly) a DS
+ record. The security status of the subzone is determined by the
+ presence or absence of the DS RRset, cryptographically proven by the
+ NSEC record. Opt-In expands this definition by allowing insecure
+ delegations to exist within an otherwise signed zone without the
+ corresponding NSEC record at the delegation's owner name. These
+ insecure delegations are proven insecure by using a covering NSEC
+ record.
+
+ Since this represents a change of the interpretation of NSEC records,
+ resolvers must be able to distinguish between RFC standard DNSSEC
+ NSEC records and Opt-In NSEC records. This is accomplished by
+ "tagging" the NSEC records that cover (or potentially cover) insecure
+ delegation nodes. This tag is indicated by the absence of the NSEC
+ bit in the type map. Since the NSEC bit in the type map merely
+ indicates the existence of the record itself, this bit is redundant
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 4]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ and safe for use as a tag.
+
+ An Opt-In tagged NSEC record does not assert the (non)existence of
+ the delegations that it covers (except for a delegation with the same
+ name). This allows for the addition or removal of these delegations
+ without recalculating or resigning records in the NSEC chain.
+ However, Opt-In tagged NSEC records do assert the (non)existence of
+ other RRsets.
+
+ An Opt-In NSEC record MAY have the same name as an insecure
+ delegation. In this case, the delegation is proven insecure by the
+ lack of a DS bit in type map and the signed NSEC record does assert
+ the existence of the delegation.
+
+ Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
+ records and standard DNSSEC NSEC records. If a NSEC record is not
+ Opt-In, there MUST NOT be any insecure delegations (or any other
+ records) between it and the RRsets indicated by the 'next domain
+ name' in the NSEC RDATA. If it is Opt-In, there MUST only be
+ insecure delegations between it and the next node indicated by the
+ 'next domain name' in the NSEC RDATA.
+
+ In summary,
+
+ o An Opt-In NSEC type is identified by a zero-valued (or not-
+ specified) NSEC bit in the type bit map of the NSEC record.
+ o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
+ the type bit map of the NSEC record.
+
+ and,
+
+ o An Opt-In NSEC record does not assert the non-existence of a name
+ between its owner name and "next" name, although it does assert
+ that any name in this span MUST be an insecure delegation.
+ o An Opt-In NSEC record does assert the (non)existence of RRsets
+ with the same owner name.
+
+4.1 Server Considerations
+
+ Opt-In imposes some new requirements on authoritative DNS servers.
+
+4.1.1 Delegations Only
+
+ This specification dictates that only insecure delegations may exist
+ between the owner and "next" names of an Opt-In tagged NSEC record.
+ Signing tools SHOULD NOT generate signed zones that violate this
+ restriction. Servers SHOULD refuse to load and/or serve zones that
+ violate this restriction. Servers also SHOULD reject AXFR or IXFR
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 5]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ responses that violate this restriction.
+
+4.1.2 Insecure Delegation Responses
+
+ When returning an Opt-In insecure delegation, the server MUST return
+ the covering NSEC RRset in the Authority section.
+
+ In standard DNSSEC, NSEC records already must be returned along with
+ the insecure delegation. The primary difference that this proposal
+ introduces is that the Opt-In tagged NSEC record will have a
+ different owner name from the delegation RRset. This may require
+ implementations to search for the covering NSEC RRset.
+
+4.1.3 Wildcards and Opt-In
+
+ Standard DNSSEC describes the practice of returning NSEC records to
+ prove the non-existence of an applicable wildcard in non-existent
+ name responses. This NSEC record can be described as a "negative
+ wildcard proof". The use of Opt-In NSEC records changes the
+ necessity for this practice. For non-existent name responses when
+ the query name (qname) is covered by an Opt-In tagged NSEC record,
+ servers MAY choose to omit the wildcard proof record, and clients
+ MUST NOT treat the absence of this NSEC record as a validation error.
+
+ The intent of the standard DNSSEC negative wildcard proof requirement
+ is to prevent malicious users from undetectably removing valid
+ wildcard responses. In order for this cryptographic proof to work,
+ the resolver must be able to prove:
+
+ 1. The exact qname does not exist. This is done by the "normal"
+ NSEC record.
+ 2. No applicable wildcard exists. This is done by returning a NSEC
+ record proving that the wildcard does not exist (this is the
+ negative wildcard proof).
+
+ However, if the NSEC record covering the exact qname is an Opt-In
+ NSEC record, the resolver will not be able to prove the first part of
+ this equation, as the qname might exist as an insecure delegation.
+ Thus, since the total proof cannot be completed, the negative
+ wildcard proof NSEC record is not useful.
+
+ The negative wildcard proof is also not useful when returned as part
+ of an Opt-In insecure delegation response for a similar reason: the
+ resolver cannot prove that the qname does or does not exist, and
+ therefore cannot prove that a wildcard expansion is valid.
+
+ The presence of an Opt-In tagged NSEC record does not change the
+ practice of returning a NSEC along with a wildcard expansion. Even
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 6]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ though the Opt-In NSEC will not be able to prove that the wildcard
+ expansion is valid, it will prove that the wildcard expansion is not
+ masking any signed records.
+
+4.1.4 Dynamic Update
+
+ Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In
+ particular, it introduces the need for rules that describe when to
+ add or remove a delegation name from the NSEC chain. This document
+ does not attempt to define these rules. Until these rules are
+ defined, servers MUST NOT process DNS Dynamic Update requests against
+ zones that use Opt-In NSEC records. Servers SHOULD return responses
+ to update requests with RCODE=REFUSED.
+
+4.2 Client Considerations
+
+ Opt-In imposes some new requirements on security-aware resolvers
+ (caching or otherwise).
+
+4.2.1 Delegations Only
+
+ As stated in the "Server Considerations" section above, this
+ specification restricts the namespace covered by Opt-In tagged NSEC
+ records to insecure delegations only. Thus, resolvers MUST reject as
+ invalid any records that fall within an Opt-In NSEC record's span
+ that are not NS records or corresponding glue records.
+
+4.2.2 Validation Process Changes
+
+ This specification does not change the resolver's resolution
+ algorithm. However, it does change the DNSSEC validation process.
+ Resolvers MUST be able to use Opt-In tagged NSEC records to
+ cryptographically prove the validity and security status (as
+ insecure) of a referral. Resolvers determine the security status of
+ the referred-to zone as follows:
+
+ o In standard DNSSEC, the security status is proven by the existence
+ or absence of a DS RRset at the same name as the delegation. The
+ existence of the DS RRset indicates that the referred-to zone is
+ signed. The absence of the DS RRset is proven using a verified
+ NSEC record of the same name that does not have the DS bit set in
+ the type map. This NSEC record MAY also be tagged as Opt-In.
+ o Using Opt-In, the security status is proven by the existence of a
+ DS record (for signed) or the presence of a verified Opt-In tagged
+ NSEC record that covers the delegation name. That is, the NSEC
+ record does not have the NSEC bit set in the type map, and the
+ delegation name falls between the NSEC's owner and "next" name.
+
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 7]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ Using Opt-In does not substantially change the nature of following
+ referrals within DNSSEC. At every delegation point, the resolver
+ will have cryptographic proof that the referred-to subzone is signed
+ or unsigned.
+
+ When receiving either an Opt-In insecure delegation response or a
+ non-existent name response where that name is covered by an Opt-In
+ tagged NSEC record, the resolver MUST NOT require proof (in the form
+ of a NSEC record) that a wildcard did not exist.
+
+4.2.3 NSEC Record Caching
+
+ Caching resolvers MUST be able to retrieve the appropriate covering
+ Opt-In NSEC record when returning referrals that need them. This
+ requirement differs from standard DNSSEC in that the covering NSEC
+ will not have the same owner name as the delegation. Some
+ implementations may have to use new methods for finding these NSEC
+ records.
+
+4.2.4 Use of the AD bit
+
+ The AD bit, as defined by [2] and [5], MUST NOT be set when:
+
+ o sending a Name Error (RCODE=3) response where the covering NSEC is
+ tagged as Opt-In.
+ o sending an Opt-In insecure delegation response, unless the
+ covering (Opt-In) NSEC record's owner name equals the delegation
+ name.
+
+ This rule is based on what the Opt-In NSEC record actually proves:
+ for names that exist between the Opt-In NSEC record's owner and
+ "next" names, the Opt-In NSEC record cannot prove the non-existence
+ or existence of the name. As such, not all data in the response has
+ been cryptographically verified, so the AD bit cannot be set.
+
+5. Benefits
+
+ Using Opt-In allows administrators of large and/or changing
+ delegation-centric zones to minimize the overhead involved in
+ maintaining the security of the zone.
+
+ Opt-In accomplishes this by eliminating the need for NSEC records for
+ insecure delegations. This, in a zone with a large number of
+ delegations to unsigned subzones, can lead to substantial space
+ savings (both in memory and on disk). Additionally, Opt-In allows
+ for the addition or removal of insecure delegations without modifying
+ the NSEC record chain. Zones that are frequently updating insecure
+ delegations (e.g., TLDs) can avoid the substantial overhead of
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 8]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ modifying and resigning the affected NSEC records.
+
+6. Example
+
+ Consider the zone EXAMPLE, shown below. This is a zone where all of
+ the NSEC records are tagged as Opt-In.
+
+ Example A: Fully Opt-In Zone.
+
+ EXAMPLE. SOA ...
+ EXAMPLE. RRSIG SOA ...
+ EXAMPLE. NS FIRST-SECURE.EXAMPLE.
+ EXAMPLE. RRSIG NS ...
+ EXAMPLE. DNSKEY ...
+ EXAMPLE. RRSIG DNSKEY ...
+ EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (
+ SOA NS RRSIG DNSKEY )
+ EXAMPLE. RRSIG NSEC ...
+
+ FIRST-SECURE.EXAMPLE. A ...
+ FIRST-SECURE.EXAMPLE. RRSIG A ...
+ FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG
+ FIRST-SECURE.EXAMPLE. RRSIG NSEC ...
+
+ NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
+ NS.NOT-SECURE.EXAMPLE. A ...
+
+ NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
+ NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG
+ NOT-SECURE-2.EXAMPLE RRSIG NSEC ...
+
+ SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE.
+ SECOND-SECURE.EXAMPLE. DS ...
+ SECOND-SECURE.EXAMPLE. RRSIG DS ...
+ SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY
+ SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
+
+ UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE.
+ NS.UNSIGNED.EXAMPLE. A ...
+
+
+ In this example, a query for a signed RRset (e.g., "FIRST-
+ SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
+ SECURE.EXAMPLE A") will result in a standard DNSSEC response.
+
+ A query for a nonexistent RRset will result in a response that
+ differs from standard DNSSEC by: the NSEC record will be tagged as
+ Opt-In, there may be no NSEC record proving the non-existence of a
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 9]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ matching wildcard record, and the AD bit will not be set.
+
+ A query for an insecure delegation RRset (or a referral) will return
+ both the answer (in the Authority section) and the corresponding
+ Opt-In NSEC record to prove that it is not secure.
+
+ Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
+
+
+ RCODE=NOERROR, AD=0
+
+ Answer Section:
+
+ Authority Section:
+ UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE
+ SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS
+ SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
+
+ Additional Section:
+ NS.UNSIGNED.EXAMPLE. A ...
+
+ In the Example A.1 zone, the EXAMPLE. node MAY use either style of
+ NSEC record, because there are no insecure delegations that occur
+ between it and the next node, FIRST-SECURE.EXAMPLE. In other words,
+ Example A would still be a valid zone if the NSEC record for EXAMPLE.
+ was changed to the following RR:
+
+ EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS
+ RRSIG DNSKEY NSEC )
+
+ However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
+ SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure
+ delegations in the range they define. (NOT-SECURE.EXAMPLE. and
+ UNSIGNED.EXAMPLE., respectively).
+
+ NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
+ part of the NSEC chain and also covered by an Opt-In tagged NSEC
+ record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
+ removed from the zone without modifying and resigning the prior NSEC
+ record. Delegations with names that fall between NOT-SECURE-
+ 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
+ resigning any NSEC records.
+
+7. Transition Issues
+
+ Opt-In is not backwards compatible with standard DNSSEC and is
+ considered experimental. Standard DNSSEC compliant implementations
+ would not recognize Opt-In tagged NSEC records as different from
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 10]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ standard NSEC records. Because of this, standard DNSSEC
+ implementations, if they were to validate Opt-In style responses,
+ would reject all Opt-In insecure delegations within a zone as
+ invalid. However, by only signing with private algorithms, standard
+ DNSSEC implementations will treat Opt-In responses as unsigned.
+
+ It should be noted that all elements in the resolution path between
+ (and including) the validator and the authoritative name server must
+ be aware of the Opt-In experiment and implement the Opt-In semantics
+ for successful validation to be possible. In particular, this
+ includes any caching middleboxes between the validator and
+ authoritative name server.
+
+8. Security Considerations
+
+ Opt-In allows for unsigned names, in the form of delegations to
+ unsigned subzones, to exist within an otherwise signed zone. All
+ unsigned names are, by definition, insecure, and their validity or
+ existence cannot by cryptographically proven.
+
+ In general:
+
+ o Records with unsigned names (whether existing or not) suffer from
+ the same vulnerabilities as records in an unsigned zone. These
+ vulnerabilities are described in more detail in [12] (note in
+ particular sections 2.3, "Name Games" and 2.6, "Authenticated
+ Denial").
+ o Records with signed names have the same security whether or not
+ Opt-In is used.
+
+ Note that with or without Opt-In, an insecure delegation may have its
+ contents undetectably altered by an attacker. Because of this, the
+ primary difference in security that Opt-In introduces is the loss of
+ the ability to prove the existence or nonexistence of an insecure
+ delegation within the span of an Opt-In NSEC record.
+
+ In particular, this means that a malicious entity may be able to
+ insert or delete records with unsigned names. These records are
+ normally NS records, but this also includes signed wildcard
+ expansions (while the wildcard record itself is signed, its expanded
+ name is an unsigned name).
+
+ For example, if a resolver received the following response from the
+ example zone above:
+
+
+
+
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 11]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
+
+ RCODE=NOERROR
+
+ Answer Section:
+
+ Authority Section:
+ DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
+ EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
+ RRSIG DNSKEY
+ EXAMPLE. RRSIG NSEC ...
+
+ Additional Section:
+
+
+ The resolver would have no choice but to believe that the referral to
+ NS.FORGED. is valid. If a wildcard existed that would have been
+ expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+ have undetectably removed it and replaced it with the forged
+ delegation.
+
+ Note that being able to add a delegation is functionally equivalent
+ to being able to add any record type: an attacker merely has to forge
+ a delegation to nameserver under his/her control and place whatever
+ records needed at the subzone apex.
+
+ While in particular cases, this issue may not present a significant
+ security problem, in general it should not be lightly dismissed.
+ Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+ In particular, zone signing tools SHOULD NOT default to Opt-In, and
+ MAY choose to not support Opt-In at all.
+
+9. IANA Considerations
+
+ None.
+
+10. Acknowledgments
+
+ The contributions, suggestions and remarks of the following persons
+ (in alphabetic order) to this draft are acknowledged:
+
+ Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
+ Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
+ Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
+ Wellington.
+
+11. References
+
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 12]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+11.1 Normative References
+
+ [1] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+ Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+ [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
+ [6] Blacka, D., "DNSSEC Experiments",
+ draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
+ July 2005.
+
+11.2 Informative References
+
+ [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+ RFC 2181, July 1997.
+
+ [9] Eastlake, D., "Secure Domain Name System Dynamic Update",
+ RFC 2137, April 1997.
+
+ [10] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+ [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
+ December 2001.
+
+ [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+ System (DNS)", RFC 3833, August 2004.
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 13]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+Authors' Addresses
+
+ Roy Arends
+ Telematica Instituut
+ Drienerlolaan 5
+ 7522 NB Enschede
+ NL
+
+ Email: roy.arends@telin.nl
+
+
+ Mark Kosters
+ Verisign, Inc.
+ 21355 Ridgetop Circle
+ Dulles, VA 20166
+ US
+
+ Phone: +1 703 948 3200
+ Email: markk@verisign.com
+ URI: http://www.verisignlabs.com
+
+
+ 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
+
+Appendix A. Implementing Opt-In using "Views"
+
+ In many cases, it may be convenient to implement an Opt-In zone by
+ combining two separately maintained "views" of a zone at request
+ time. In this context, "view" refers to a particular version of a
+ zone, not to any specific DNS implementation feature.
+
+ In this scenario, one view is the secure view, the other is the
+ insecure (or legacy) view. The secure view consists of an entirely
+ signed zone using Opt-In tagged NSEC records. The insecure view
+ contains no DNSSEC information. It is helpful, although not
+ necessary, for the secure view to be a subset (minus DNSSEC records)
+ of the insecure view.
+
+ In addition, the only RRsets that may solely exist in the insecure
+ view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 14]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+ the zone apex NS RRset) MUST be signed and in the secure view.
+
+ These two views may be combined at request time to provide a virtual,
+ single Opt-In zone. The following algorithm is used when responding
+ to each query:
+ V_A is the secure view as described above.
+ V_B is the insecure view as described above.
+ R_A is a response generated from V_A, following RFC 2535bis.
+ R_B is a response generated from V_B, following DNS resolution as
+ per RFC 1035 [1].
+ R_C is the response generated by combining R_A with R_B, as
+ described below.
+ A query is DNSSEC-aware if it either has the DO bit [11] turned
+ on, or is for a DNSSEC-specific record type.
+
+
+
+ 1. If V_A is a subset of V_B and the query is not DNSSEC-aware,
+ generate and return R_B, otherwise
+ 2. Generate R_A.
+ 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise
+ 4. Generate R_B and combine it with R_A to form R_C:
+ For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
+ records from R_A into R_B, EXCEPT the AUTHORITY section SOA
+ record, if R_B's RCODE = NOERROR.
+ 5. Return R_C.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 15]
+
+Internet-Draft DNSSEC Opt-In July 2005
+
+
+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 (2005). 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.
+
+
+
+
+Arends, et al. Expires January 19, 2006 [Page 16]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
new file mode 100644
index 0000000..390420a
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
@@ -0,0 +1,392 @@
+
+
+
+DNS Extensions working group J. Jansen
+Internet-Draft NLnet Labs
+Expires: July 5, 2006 January 2006
+
+
+ Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
+ draft-ietf-dnsext-dnssec-rsasha256-00
+
+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 July 5, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
+ resource records for use in the Domain Name System Security
+ Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
+
+
+
+
+
+
+
+
+
+Jansen Expires July 5, 2006 [Page 1]
+
+Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
+ 3. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . . . 3
+ 4. Implementation Considerations . . . . . . . . . . . . . . . . . 4
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Intellectual Property and Copyright Statements . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen Expires July 5, 2006 [Page 2]
+
+Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
+
+
+1. Introduction
+
+ The Domain Name System (DNS) is the global hierarchical distributed
+ database for Internet Addressing. The DNS has been extended to use
+ digital signatures and cryptographic keys for the verification of
+ data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
+ Security Extensions.
+
+ RFC4034 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 algorithm RSA/SHA-256, and specifies how
+ to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
+ resource records.
+
+ Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
+ this document.
+
+
+2. RSA/SHA-256 DNSKEY Resource Records
+
+ RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
+ resource records (RRs) with the algorithm number [TBA].
+
+ The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
+ [6].
+
+
+3. RSA/SHA-256 RRSIG Resource Records
+
+ RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
+ records (RRs) with algorithm number [TBA].
+
+ The value of the signature field in the RRSIG RR is calculated as
+ follows. The values for the fields that precede the signature data
+ are specified in RFC4034 [2].
+
+ hash = SHA-256(data)
+
+ signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
+
+ Where SHA-256 is the message digest algorithm as specified in FIPS
+ 180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
+ corresponding hexadecimal value, "e" is the private exponent of the
+ signing RSA key, and "n" is the public modulus of the signing key.
+ The FF octet MUST be repeated the maximum number of times so that the
+ total length of the signature equals the length of the modulus of the
+ signer's public key ("n"). "data" is the data of the resource record
+ set that is signed, as specified in RFC4034 [2].
+
+
+
+Jansen Expires July 5, 2006 [Page 3]
+
+Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
+
+
+ The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
+ specified in PKCS 2.1 [4]:
+
+ hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
+
+ This prefix should make the use of standard cryptographic libraries
+ easier. These specifications are taken directly from PKCS #1 v2.1
+ section 9.2 [4].
+
+
+4. Implementation Considerations
+
+ DNSSEC aware implementations MUST be able to support RRSIG resource
+ records with the RSA/SHA-256 algorithm.
+
+ If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
+ available for a certain rrset, with a secure path to their keys, the
+ validator SHOULD ignore the SHA-1 signature. If the RSA/SHA-256
+ signature does not verify the data, and the RSA/SHA-1 does, the
+ validator SHOULD mark the data with the security status from the RSA/
+ SHA-256 signature.
+
+
+5. IANA Considerations
+
+ IANA has not yet assigned an algorithm number for RSA/SHA-256.
+
+ The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
+ following entry:
+
+ Zone
+ Value Algorithm [Mnemonic] Signing References Status
+ ----- ----------- ----------- -------- ---------- ---------
+ [tba] RSA/SHA-256 [RSASHA256] y [TBA] MANDATORY
+
+
+6. Security Considerations
+
+ Recently, weaknesses have been discovered in the SHA-1 hashing
+ algorithm. It is therefore strongly encouraged to deploy SHA-256
+ where SHA-1 is used now, as soon as the DNS software supports it.
+
+ SHA-256 is considered sufficiently strong for the immediate future,
+ but predictions about future development in cryptography and
+ cryptanalysis are beyond the scope of this document.
+
+
+
+
+
+
+Jansen Expires July 5, 2006 [Page 4]
+
+Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
+
+
+7. Acknowledgments
+
+ This document is a minor extension to RFC4034 [2]. Also, we try to
+ follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
+ [8] 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: Jaap
+ Akkerhuis, Miek Gieben and Wouter Wijngaards.
+
+
+8. References
+
+8.1. Normative References
+
+ [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
+ [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
+ (PKCS) #1: RSA Cryptography Specifications Version 2.1",
+ RFC 3447, February 2003.
+
+ [5] National Institute of Standards and Technology, "Secure Hash
+ Standard", FIPS PUB 180-2, August 2002.
+
+ [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
+ System (DNS)", RFC 3110, May 2001.
+
+8.2. Informative References
+
+ [7] Schneier, B., "Applied Cryptography Second Edition: protocols,
+ algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
+ 11709-9, 1996.
+
+ [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+ Resource Records (RRs)", Work in Progress Feb 2006.
+
+
+
+
+
+
+Jansen Expires July 5, 2006 [Page 5]
+
+Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
+
+
+Author's Address
+
+ Jelte Jansen
+ NLnet Labs
+ Kruislaan 419
+ Amsterdam 1098VA
+ NL
+
+ Email: jelte@NLnetLabs.nl
+ URI: http://www.nlnetlabs.nl/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jansen Expires July 5, 2006 [Page 6]
+
+Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 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.
+
+
+
+
+Jansen Expires July 5, 2006 [Page 7]
+
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
new file mode 100644
index 0000000..dd8cbf0
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
@@ -0,0 +1,839 @@
+
+DNS Extensions Working Group R. Arends
+Internet-Draft Telematica Instituut
+Expires: August 25, 2005 P. Koch
+ DENIC eG
+ J. Schlyter
+ NIC-SE
+ February 21, 2005
+
+
+ Evaluating DNSSEC Transition Mechanisms
+ draft-ietf-dnsext-dnssec-trans-02.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ 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 25, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document collects and summarizes different proposals for
+ alternative and additional strategies for authenticated denial in DNS
+ responses, evaluates these proposals and gives a recommendation for a
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 1]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+ way forward.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
+ 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4
+ 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
+ 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5
+ 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
+ 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6
+ 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
+ 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8
+ 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
+ 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9
+ 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
+ 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10
+ 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11
+ 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
+ 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
+ 5.2 Informative References . . . . . . . . . . . . . . . . . . 13
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
+ Intellectual Property and Copyright Statements . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 2]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+1. Introduction
+
+ This report shall document the process of dealing with the NSEC
+ walking problem late in the Last Call for
+ [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
+ I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion
+ that took place in the DNSEXT WG during the first half of June 2004
+ as well as some additional ideas that came up subsequently.
+
+ This is an edited excerpt of the chairs' mail to the WG:
+ The working group consents on not including NSEC-alt in the
+ DNSSEC-bis documents. The working group considers to take up
+ "prevention of zone enumeration" as a work item.
+ There may be multiple mechanisms to allow for co-existence with
+ DNSSEC-bis. The chairs allow the working group a little over a
+ week (up to June 12, 2004) to come to consensus on a possible
+ modification to the document to enable gentle rollover. If that
+ consensus cannot be reached the DNSSEC-bis documents will go out
+ as-is.
+
+ To ease the process of getting consensus, a summary of the proposed
+ solutions and analysis of the pros and cons were written during the
+ weekend.
+
+ This summary includes:
+
+ An inventory of the proposed mechanisms to make a transition to
+ future work on authenticated denial of existence.
+ List the known Pros and Cons, possibly provide new arguments, and
+ possible security considerations of these mechanisms.
+ Provide a recommendation on a way forward that is least disruptive
+ to the DNSSEC-bis specifications as they stand and keep an open
+ path to other methods for authenticated denial of existence.
+
+ The descriptions of the proposals in this document are coarse and do
+ not cover every detail necessary for implementation. In any case,
+ documentation and further study is needed before implementaion and/or
+ deployment, including those which seem to be solely operational in
+ nature.
+
+2. Transition Mechanisms
+
+ In the light of recent discussions and past proposals, we have found
+ several ways to allow for transition to future expansion of
+ authenticated denial. We tried to illuminate the paths and pitfalls
+ in these ways forward. Some proposals lead to a versioning of
+ DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
+ proposals are 'clean' but may cause delay, while again others may be
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 3]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+ plain hacks.
+
+ Some paths do not introduce versioning, and might require the current
+ DNSSEC-bis documents to be fully updated to allow for extensions to
+ authenticated denial mechanisms. Other paths introduce versioning
+ and do not (or minimally) require DNSSEC-bis documents to be updated,
+ allowing DNSSEC-bis to be deployed, while future versions can be
+ drafted independent from or partially depending on DNSSEC-bis.
+
+2.1 Mechanisms With Need of Updating DNSSEC-bis
+
+ Mechanisms in this category demand updates to the DNSSEC-bis document
+ set.
+
+2.1.1 Dynamic NSEC Synthesis
+
+ This proposal assumes that NSEC RRs and the authenticating RRSIG will
+ be generated dynamically to just cover the (non existent) query name.
+ The owner name is (the) one preceding the name queried for, the Next
+ Owner Name Field has the value of the Query Name Field + 1 (first
+ successor in canonical ordering). A separate key (the normal ZSK or
+ a separate ZSK per authoritative server) would be used for RRSIGs on
+ NSEC RRs. This is a defense against enumeration, though it has the
+ presumption of online signing.
+
+2.1.1.1 Coexistence and Migration
+
+ There is no change in interpretation other then that the next owner
+ name might or might not exist.
+
+2.1.1.2 Limitations
+
+ This introduces an unbalanced cost between query and response
+ generation due to dynamic generation of signatures.
+
+2.1.1.3 Amendments to DNSSEC-bis
+
+ The current DNSSEC-bis documents might need to be updated to indicate
+ that the next owner name might not be an existing name in the zone.
+ This is not a real change to the spec since implementers have been
+ warned not to synthesize with previously cached NSEC records. A
+ specific bit to identify the dynamic signature generating key might
+ be useful as well, to prevent it from being used to fake positive
+ data.
+
+2.1.1.4 Cons
+
+ Unbalanced cost is a ground for DDoS. Though this protects against
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 4]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+ enumeration, it is not really a path for versioning.
+
+2.1.1.5 Pros
+
+ Hardly any amendments to DNSSEC-bis.
+
+2.1.2 Add Versioning/Subtyping to Current NSEC
+
+ This proposal introduces versioning for the NSEC RR type (a.k.a.
+ subtyping) by adding a (one octet) version field to the NSEC RDATA.
+ Version number 0 is assigned to the current (DNSSEC-bis) meaning,
+ making this an 'Must Be Zero' (MBZ) for the to be published docset.
+
+2.1.2.1 Coexistence and Migration
+
+ Since the versioning is done inside the NSEC RR, different versions
+ may coexist. However, depending on future methods, that may or may
+ not be useful inside a single zone. Resolvers cannot ask for
+ specific NSEC versions but may be able to indicate version support by
+ means of a to be defined EDNS option bit.
+
+2.1.2.2 Limitations
+
+ There are no technical limitations, though it will cause delay to
+ allow testing of the (currently unknown) new NSEC interpretation.
+
+ Since the versioning and signaling is done inside the NSEC RR, future
+ methods will likely be restricted to a single RR type authenticated
+ denial (as opposed to e.g. NSEC-alt, which currently proposes three
+ RR types).
+
+2.1.2.3 Amendments to DNSSEC-bis
+
+ Full Update of the current DNSSEC-bis documents to provide for new
+ fields in NSEC, while specifying behavior in case of unknown field
+ values.
+
+2.1.2.4 Cons
+
+ Though this is a clean and clear path without versioning DNSSEC, it
+ takes some time to design, gain consensus, update the current
+ dnssec-bis document, test and implement a new authenticated denial
+ record.
+
+2.1.2.5 Pros
+
+ Does not introduce an iteration to DNSSEC while providing a clear and
+ clean migration strategy.
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 5]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+2.1.3 Type Bit Map NSEC Indicator
+
+ Bits in the type-bit-map are reused or allocated to signify the
+ interpretation of NSEC.
+
+ This proposal assumes that future extensions make use of the existing
+ NSEC RDATA syntax, while it may need to change the interpretation of
+ the RDATA or introduce an alternative denial mechanism, invoked by
+ the specific type-bit-map-bits.
+
+2.1.3.1 Coexistence and migration
+
+ Old and new NSEC meaning could coexist, depending how the signaling
+ would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR
+ types are available as well as those covering meta/query types or
+ types to be specifically allocated.
+
+2.1.3.2 Limitations
+
+ This mechanism uses an NSEC field that was not designed for that
+ purpose. Similar methods were discussed during the Opt-In discussion
+ and the Silly-State discussion.
+
+2.1.3.3 Amendments to DNSSEC-bis
+
+ The specific type-bit-map-bits must be allocated and they need to be
+ specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
+ interpretation. Also, behaviour of the resolver and validator must
+ be documented in case unknown values are encountered for the MBZ
+ field. Currently the protocol document specifies that the validator
+ MUST ignore the setting of the NSEC and the RRSIG bits, while other
+ bits are only used for the specific purpose of the type-bit-map field
+
+2.1.3.4 Cons
+
+ The type-bit-map was not designed for this purpose. It is a
+ straightforward hack. Text in protocol section 5.4 was put in
+ specially to defend against this usage.
+
+2.1.3.5 Pros
+
+ No change needed to the on-the-wire protocol as specified in the
+ current docset.
+
+2.1.4 New Apex Type
+
+ This introduces a new Apex type (parallel to the zone's SOA)
+ indicating the DNSSEC version (or authenticated denial) used in or
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 6]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+ for this zone.
+
+2.1.4.1 Coexistence and Migration
+
+ Depending on the design of this new RR type multiple denial
+ mechanisms may coexist in a zone. Old validators will not understand
+ and thus ignore the new type, so interpretation of the new NSEC
+ scheme may fail, negative responses may appear 'bogus'.
+
+2.1.4.2 Limitations
+
+ A record of this kind is likely to carry additional
+ feature/versioning indications unrelated to the current question of
+ authenticated denial.
+
+2.1.4.3 Amendments to DNSSEC-bis
+
+ The current DNSSEC-bis documents need to be updated to indicate that
+ the absence of this type indicates dnssec-bis, and that the (mere)
+ presence of this type indicated unknown versions.
+
+2.1.4.4 Cons
+
+ The only other 'zone' or 'apex' record is the SOA record. Though
+ this proposal is not new, it is yet unknown how it might fulfill
+ authenticated denial extensions. This new RR type would only provide
+ for a generalized signaling mechanism, not the new authenticated
+ denial scheme. Since it is likely to be general in nature, due to
+ this generality consensus is not to be reached soon.
+
+2.1.4.5 Pros
+
+ This approach would allow for a lot of other per zone information to
+ be transported or signaled to both (slave) servers and resolvers.
+
+2.1.5 NSEC White Lies
+
+ This proposal disables one part of NSEC (the pointer part) by means
+ of a special target (root, apex, owner, ...), leaving intact only the
+ ability to authenticate denial of existence of RR sets, not denial of
+ existence of domain names (NXDOMAIN). It may be necessary to have
+ one working NSEC to prove the absence of a wildcard.
+
+2.1.5.1 Coexistence and Migration
+
+ The NSEC target can be specified per RR, so standard NSEC and 'white
+ lie' NSEC can coexist in a zone. There is no need for migration
+ because no versioning is introduced or intended.
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 7]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+2.1.5.2 Limitations
+
+ This proposal breaks the protocol and is applicable to certain types
+ of zones only (no wildcard, no deep names, delegation only). Most of
+ the burden is put on the resolver side and operational consequences
+ are yet to be studied.
+
+2.1.5.3 Amendments to DNSSEC-bis
+
+ The current DNSSEC-bis documents need to be updated to indicate that
+ the NXDOMAIN responses may be insecure.
+
+2.1.5.4 Cons
+
+ Strictly speaking this breaks the protocol and doesn't fully fulfill
+ the requirements for authenticated denial of existence. Security
+ implications need to be carefully documented: search path problems
+ (forged denial of existence may lead to wrong expansion of non-FQDNs
+ [RFC1535]) and replay attacks to deny existence of records.
+
+2.1.5.5 Pros
+
+ Hardly any amendments to DNSSEC-bis. Operational "trick" that is
+ available anyway.
+
+2.1.6 NSEC Optional via DNSSKEY Flag
+
+ A new DNSKEY may be defined to declare NSEC optional per zone.
+
+2.1.6.1 Coexistence and Migration
+
+ Current resolvers/validators will not understand the Flag bit and
+ will have to treat negative responses as bogus. Otherwise, no
+ migration path is needed since NSEC is simply turned off.
+
+2.1.6.2 Limitations
+
+ NSEC can only be made completely optional at the cost of being unable
+ to prove unsecure delegations (absence of a DS RR [RFC3658]). A next
+ to this approach would just disable authenticated denial for
+ non-existence of nodes.
+
+2.1.6.3 Amendments to DNSSEC-bis
+
+ New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
+ be specified in the light of absence of authenticated denial.
+
+
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 8]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+2.1.6.4 Cons
+
+ Doesn't fully meet requirements. Operational consequences to be
+ studied.
+
+2.1.6.5 Pros
+
+ Official version of the "trick" presented in (8). Operational
+ problems can be addressed during future work on validators.
+
+2.1.7 New Answer Pseudo RR Type
+
+ A new pseudo RR type may be defined that will be dynamically created
+ (and signed) by the responding authoritative server. The RR in the
+ response will cover the QNAME, QCLASS and QTYPE and will authenticate
+ both denial of existence of name (NXDOMAIN) or RRset.
+
+2.1.7.1 Coexistence and Migration
+
+ Current resolvers/validators will not understand the pseudo RR and
+ will thus not be able to process negative responses so testified. A
+ signaling or solicitation method would have to be specified.
+
+2.1.7.2 Limitations
+
+ This method can only be used with online keys and online signing
+ capacity.
+
+2.1.7.3 Amendments to DNSSEC-bis
+
+ Signaling method needs to be defined.
+
+2.1.7.4 Cons
+
+ Keys have to be held and processed online with all security
+ implications. An additional flag for those keys identifying them as
+ online or negative answer only keys should be considered.
+
+2.1.7.5 Pros
+
+ Expands DNSSEC authentication to the RCODE.
+
+2.1.8 SIG(0) Based Authenticated Denial
+
+
+2.1.8.1 Coexistence and Migration
+
+
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 9]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+2.1.8.2 Limitations
+
+
+2.1.8.3 Amendments to DNSSEC-bis
+
+
+2.1.8.4 Cons
+
+
+2.1.8.5 Pros
+
+
+2.2 Mechanisms Without Need of Updating DNSSEC-bis
+
+2.2.1 Partial Type-code and Signal Rollover
+
+ Carefully crafted type code/signal rollover to define a new
+ authenticated denial space that extends/replaces DNSSEC-bis
+ authenticated denial space. This particular path is illuminated by
+ Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
+ posted to <namedroppers@ops.ietf.org> 2004-06-02.
+
+2.2.1.1 Coexistence and Migration
+
+ To protect the current resolver for future versions, a new DNSSEC-OK
+ bit must be allocated to make clear it does or does not understand
+ the future version. Also, a new DS type needs to be allocated to
+ allow differentiation between a current signed delegation and a
+ 'future' signed delegation. Also, current NSEC needs to be rolled
+ into a new authenticated denial type.
+
+2.2.1.2 Limitations
+
+ None.
+
+2.2.1.3 Amendments to DNSSEC-bis
+
+ None.
+
+2.2.1.4 Cons
+
+ It is cumbersome to carefully craft an TCR that 'just fits'. The
+ DNSSEC-bis protocol has many 'borderline' cases that needs special
+ consideration. It might be easier to do a full TCR, since a few of
+ the types and signals need upgrading anyway.
+
+
+
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 10]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+2.2.1.5 Pros
+
+ Graceful adoption of future versions of NSEC, while there are no
+ amendments to DNSSEC-bis.
+
+2.2.2 A Complete Type-code and Signal Rollover
+
+ A new DNSSEC space is defined which can exist independent of current
+ DNSSEC-bis space.
+
+ This proposal assumes that all current DNSSEC type-codes
+ (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
+ future versions of DNSSEC. Any future version of DNSSEC has its own
+ types to allow for keys, signatures, authenticated denial, etcetera.
+
+2.2.2.1 Coexistence and Migration
+
+ Both spaces can co-exist. They can be made completely orthogonal.
+
+2.2.2.2 Limitations
+
+ None.
+
+2.2.2.3 Amendments to DNSSEC-bis
+
+ None.
+
+2.2.2.4 Cons
+
+ With this path we abandon the current DNSSEC-bis. Though it is easy
+ to role specific well-known and well-tested parts into the re-write,
+ once deployment has started this path is very expensive for
+ implementers, registries, registrars and registrants as well as
+ resolvers/users. A TCR is not to be expected to occur frequently, so
+ while a next generation authenticated denial may be enabled by a TCR,
+ it is likely that that TCR will only be agreed upon if it serves a
+ whole basket of changes or additions. A quick introduction of
+ NSEC-ng should not be expected from this path.
+
+2.2.2.5 Pros
+
+ No amendments/changes to current DNSSEC-bis docset needed. It is
+ always there as last resort.
+
+2.2.3 Unknown Algorithm in RRSIG
+
+ This proposal assumes that future extensions make use of the existing
+ NSEC RDATA syntax, while it may need to change the interpretation of
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 11]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+ the RDATA or introduce an alternative denial mechanism, invoked by
+ the specific unknown signing algorithm. The different interpretation
+ would be signaled by use of different signature algorithms in the
+ RRSIG records covering the NSEC RRs.
+
+ When an entire zone is signed with a single unknown algorithm, it
+ will cause implementations that follow current dnssec-bis documents
+ to treat individual RRsets as unsigned.
+
+2.2.3.1 Coexistence and migration
+
+ Old and new NSEC RDATA interpretation or known and unknown Signatures
+ can NOT coexist in a zone since signatures cover complete (NSEC)
+ RRSets.
+
+2.2.3.2 Limitations
+
+ Validating resolvers agnostic of new interpretation will treat the
+ NSEC RRset as "not signed". This affects wildcard and non-existence
+ proof, as well as proof for (un)secured delegations. Also, all
+ positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
+ insecure/bogus to an old validator.
+
+ The algorithm version space is split for each future version of
+ DNSSEC. Violation of the 'modular components' concept. We use the
+ 'validator' to protect the 'resolver' from unknown interpretations.
+
+2.2.3.3 Amendments to DNSSEC-bis
+
+ None.
+
+2.2.3.4 Cons
+
+ The algorithm field was not designed for this purpose. This is a
+ straightforward hack.
+
+2.2.3.5 Pros
+
+ No amendments/changes to current DNSSEC-bis docset needed.
+
+3. Recommendation
+
+ The authors recommend that the working group commits to and starts
+ work on a partial TCR, allowing graceful transition towards a future
+ version of NSEC. Meanwhile, to accomodate the need for an
+ immediately, temporary, solution against zone-traversal, we recommend
+ On-Demand NSEC synthesis.
+
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 12]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+ This approach does not require any mandatory changes to DNSSEC-bis,
+ does not violate the protocol and fulfills the requirements. As a
+ side effect, it moves the cost of implementation and deployment to
+ the users (zone owners) of this mechanism.
+
+4. Acknowledgements
+
+ The authors would like to thank Sam Weiler and Mark Andrews for their
+ input and constructive comments.
+
+5. References
+
+5.1 Normative References
+
+ [I-D.ietf-dnsext-dnssec-intro]
+ Arends, R., Austein, R., Massey, D., Larson, M. and S.
+ Rose, "DNS Security Introduction and Requirements",
+ Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
+ 2004.
+
+ [I-D.ietf-dnsext-dnssec-protocol]
+ Arends, R., "Protocol Modifications for the DNS Security
+ Extensions",
+ Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
+ October 2004.
+
+ [I-D.ietf-dnsext-dnssec-records]
+ Arends, R., "Resource Records for the DNS Security
+ Extensions",
+ Internet-Draft draft-ietf-dnsext-dnssec-records-11,
+ October 2004.
+
+ [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.
+
+ [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+5.2 Informative References
+
+ [RFC1535] Gavron, E., "A Security Problem and Proposed Correction
+ With Widely Deployed DNS Software", RFC 1535, October
+ 1993.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 13]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+ RFC 2535, March 1999.
+
+ [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
+ June 1999.
+
+ [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
+ (RR)", RFC 3658, December 2003.
+
+
+Authors' Addresses
+
+ Roy Arends
+ Telematica Instituut
+ Brouwerijstraat 1
+ Enschede 7523 XC
+ The Netherlands
+
+ Phone: +31 53 4850485
+ Email: roy.arends@telin.nl
+
+
+ Peter Koch
+ DENIC eG
+ Wiesenh"uttenplatz 26
+ Frankfurt 60329
+ Germany
+
+ Phone: +49 69 27235 0
+ Email: pk@DENIC.DE
+
+
+ Jakob Schlyter
+ NIC-SE
+ Box 5774
+ Stockholm SE-114 87
+ Sweden
+
+ Email: jakob@nic.se
+ URI: http://www.nic.se/
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 14]
+
+Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
+
+
+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 (2005). 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.
+
+
+
+
+Arends, et al. Expires August 25, 2005 [Page 15]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
new file mode 100644
index 0000000..2460cb6
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
@@ -0,0 +1,504 @@
+
+
+
+Network Working Group W. Hardaker
+Internet-Draft Sparta
+Expires: August 25, 2006 February 21, 2006
+
+
+ Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
+ draft-ietf-dnsext-ds-sha256-05.txt
+
+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 August 25, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document specifies how to use the SHA-256 digest type in DNS
+ Delegation Signer (DS) Resource Records (RRs). DS records, when
+ stored in a parent zone, point to key signing DNSKEY key(s) in a
+ child zone.
+
+
+
+
+
+
+
+
+Hardaker Expires August 25, 2006 [Page 1]
+
+Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Implementing the SHA-256 algorithm for DS record support . . . 3
+ 2.1. DS record field values . . . . . . . . . . . . . . . . . . 3
+ 2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3
+ 2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
+ 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
+ 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+ 6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
+ 6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ Intellectual Property and Copyright Statements . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker Expires August 25, 2006 [Page 2]
+
+Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
+
+
+1. Introduction
+
+ The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
+ zones to distribute a cryptographic digest of a child's Key Signing
+ Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the
+ parent zone's private zone data signing keys for each algorithm in
+ use by the parent. Each signature is published in an RRSIG resource
+ record, owned by the same domain as the DS RRset and with a type
+ covered of DS.
+
+ 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. Implementing the SHA-256 algorithm for DS record support
+
+ This document specifies that the digest type code [XXX: To be
+ assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
+ [SHA256CODE] for use within DS records. The results of the digest
+ algorithm MUST NOT be truncated and the entire 32 byte digest result
+ is to be published in the DS record.
+
+2.1. DS record field values
+
+ Using the SHA-256 digest algorithm within a DS record will make use
+ of the following DS-record fields:
+
+ Digest type: [XXX: To be assigned by IANA; likely 2]
+
+ Digest: A SHA-256 bit digest value calculated by using the following
+ formula ("|" denotes concatenation). The resulting value is not
+ truncated and the entire 32 byte result is to used in the
+ resulting DS record and related calculations.
+
+ digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
+
+ where DNSKEY RDATA is defined by [RFC4034] as:
+
+ DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
+
+ The Key Tag field and Algorithm fields remain unchanged by this
+ document and are specified in the [RFC4034] specification.
+
+2.2. DS Record with SHA-256 Wire Format
+
+ The resulting on-the-wire format for the resulting DS record will be
+ [XXX: IANA assignment should replace the 2 below]:
+
+
+
+Hardaker Expires August 25, 2006 [Page 3]
+
+Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
+
+
+ 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 Tag | Algorithm | DigestType=2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / /
+ / Digest (length for SHA-256 is 32 bytes) /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+2.3. Example DS Record Using SHA-256
+
+ The following is an example DNSKEY and matching DS record. This
+ DNSKEY record comes from the example DNSKEY/DS records found in
+ section 5.4 of [RFC4034].
+
+ The DNSKEY record:
+
+ dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+ fwJr1AYtsmx3TGkJaNXVbfi/
+ 2pHm822aJ5iI9BMzNXxeYCmZ
+ DRD99WYwYqUSdjMmmAphXdvx
+ egXd/M5+X7OrzKBaMbCVdFLU
+ Uh6DhweJBjEVv5f2wwjM9Xzc
+ nOf+EPbtG9DMBmADjFDc2w/r
+ ljwvFw==
+ ) ; key id = 60485
+
+ The resulting DS record covering the above DNSKEY record using a SHA-
+ 256 digest: [RFC Editor: please replace XXX with the assigned digest
+ type (likely 2):]
+
+ dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
+ CEB1E3E0614B93C4F9E99B83
+ 83F6A1E4469DA50A )
+
+
+3. Implementation Requirements
+
+ Implementations MUST support the use of the SHA-256 algorithm in DS
+ RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
+ digests if DS RRs with SHA-256 digests are present in the DS RRset.
+
+
+4. Deployment Considerations
+
+ If a validator does not support the SHA-256 digest type and no other
+ DS RR exists in a zone's DS RRset with a supported digest type, then
+
+
+
+Hardaker Expires August 25, 2006 [Page 4]
+
+Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
+
+
+ the validator 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 in [RFC4035], section 5.2.
+
+ Because zone administrators can not control the deployment speed of
+ support for SHA-256 in validators that may be referencing any of
+ their zones, zone operators should consider deploying both SHA-1 and
+ SHA-256 based DS records. This should be done for every DNSKEY for
+ which DS records are being generated. Whether to make use of both
+ digest types and for how long is a policy decision that extends
+ beyond the scope of this document.
+
+
+5. IANA Considerations
+
+ Only one IANA action is required by this document:
+
+ The Digest Type to be used for supporting SHA-256 within DS records
+ needs to be assigned by IANA. This document requests that the Digest
+ Type value of 2 be assigned to the SHA-256 digest algorithm.
+
+ At the time of this writing, the current digest types assigned for
+ use in DS records are as follows:
+
+ VALUE Digest Type Status
+ 0 Reserved -
+ 1 SHA-1 MANDATORY
+ 2 SHA-256 MANDATORY
+ 3-255 Unassigned -
+
+
+6. Security Considerations
+
+6.1. Potential Digest Type Downgrade Attacks
+
+ A downgrade attack from a stronger digest type to a weaker one is
+ possible if all of the following are true:
+
+ o A zone includes multiple DS records for a given child's DNSKEY,
+ each of which use a different digest type.
+
+ o A validator accepts a weaker digest even if a stronger one is
+ present but invalid.
+
+ For example, if the following conditions are all true:
+
+
+
+
+
+Hardaker Expires August 25, 2006 [Page 5]
+
+Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
+
+
+ o Both SHA-1 and SHA-256 based digests are published in DS records
+ within a parent zone for a given child zone's DNSKEY.
+
+ o The DS record with the SHA-1 digest matches the digest computed
+ using the child zone's DNSKEY.
+
+ o The DS record with the SHA-256 digest fails to match the digest
+ computed using the child zone's DNSKEY.
+
+ Then if the validator accepts the above situation as secure then this
+ can be used as a downgrade attack since the stronger SHA-256 digest
+ is ignored.
+
+6.2. SHA-1 vs SHA-256 Considerations for DS Records
+
+ Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
+ implementations allow for it. SHA-256 is widely believed to be more
+ resilient to attack than SHA-1, and confidence in SHA-1's strength is
+ being eroded by recently-announced attacks. Regardless of whether or
+ not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
+ time of this writing) that SHA-256 is the better choice for use in DS
+ records.
+
+ At the time of this publication, the SHA-256 digest algorithm is
+ considered sufficiently strong for the immediate future. It is also
+ considered sufficient for use in DNSSEC DS RRs for the immediate
+ future. However, future published attacks may weaken the usability
+ of this algorithm within the DS RRs. It is beyond the scope of this
+ document to speculate extensively on the cryptographic strength of
+ the SHA-256 digest algorithm.
+
+ Likewise, it is also beyond the scope of this document to specify
+ whether or for how long SHA-1 based DS records should be
+ simultaneously published alongside SHA-256 based DS records.
+
+
+7. Acknowledgments
+
+ This document is a minor extension to the existing DNSSEC documents
+ and those authors are gratefully appreciated for the hard work that
+ went into the base documents.
+
+ The following people contributed to portions of this document in some
+ fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
+ Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
+ Weiler.
+
+
+
+
+
+Hardaker Expires August 25, 2006 [Page 6]
+
+Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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.
+
+ [SHA256] National Institute of Standards and Technology, "Secure
+ Hash Algorithm. NIST FIPS 180-2", August 2002.
+
+8.2. Informative References
+
+ [SHA256CODE]
+ Eastlake, D., "US Secure Hash Algorithms (SHA)",
+ June 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker Expires August 25, 2006 [Page 7]
+
+Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
+
+
+Author's Address
+
+ Wes Hardaker
+ Sparta
+ P.O. Box 382
+ Davis, CA 95617
+ US
+
+ Email: hardaker@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardaker Expires August 25, 2006 [Page 8]
+
+Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 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.
+
+
+
+
+Hardaker Expires August 25, 2006 [Page 9]
+
diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
new file mode 100644
index 0000000..2cdcdb1
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
@@ -0,0 +1,928 @@
+
+INTERNET-DRAFT ECC Keys in the DNS
+Expires: January 2006 July 2005
+
+
+
+ Elliptic Curve KEYs in the DNS
+ -------- ----- ---- -- --- ---
+ <draft-ietf-dnsext-ecc-key-07.txt>
+
+ Richard C. Schroeppel
+ Donald 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.
+
+ This draft is intended to be become a Proposed Standard RFC.
+ Distribution of this document is unlimited. Comments should be sent
+ to the DNS 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 a "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 storing elliptic curve cryptographic keys and
+ signatures in the Domain Name System is specified.
+
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+
+
+
+
+R. Schroeppel, et al [Page 1]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+Acknowledgement
+
+ The assistance of Hilarie K. Orman in the production of this document
+ is greatfully acknowledged.
+
+
+
+Table of Contents
+
+ Status of This Document....................................1
+ Abstract...................................................1
+ Copyright Notice...........................................1
+
+ Acknowledgement............................................2
+ Table of Contents..........................................2
+
+ 1. Introduction............................................3
+ 2. Elliptic Curve Data in Resource Records.................3
+ 3. The Elliptic Curve Equation.............................9
+ 4. How do I Compute Q, G, and Y?..........................10
+ 5. Elliptic Curve SIG Resource Records....................11
+ 6. Performance Considerations.............................13
+ 7. Security Considerations................................13
+ 8. IANA Considerations....................................13
+ Copyright and Disclaimer..................................14
+
+ Informational References..................................15
+ Normative Refrences.......................................15
+
+ Author's Addresses........................................16
+ Expiration and File Name..................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al [Page 2]
+
+
+INTERNET-DRAFT ECC Keys 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. The DNS has been extended to include digital
+ signatures and cryptographic keys as described in [RFC 4033, 4034,
+ 4035].
+
+ This document describes how to store elliptic curve cryptographic
+ (ECC) keys and signatures in the DNS so they can be used for a
+ variety of security purposes. Familiarity with ECC cryptography is
+ assumed [Menezes].
+
+ 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].
+
+
+
+2. Elliptic Curve Data in Resource Records
+
+ Elliptic curve public keys are stored in the DNS within the RDATA
+ portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
+ structure shown below.
+
+ The research world continues to work on the issue of which is the
+ best elliptic curve system, which finite field to use, and how to
+ best represent elements in the field. So, representations are
+ defined for every type of finite field, and every type of elliptic
+ curve. The reader should be aware that there is a unique finite
+ field with a particular number of elements, but many possible
+ representations of that field and its elements. If two different
+ representations of a field are given, they are interconvertible with
+ a tedious but practical precomputation, followed by a fast
+ computation for each field element to be converted. It is perfectly
+ reasonable for an algorithm to work internally with one field
+ representation, and convert to and from a different external
+ representation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al [Page 3]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |S M -FMT- A B Z|
+ +-+-+-+-+-+-+-+-+
+ | LP |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | P (length determined from LP) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LF |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | F (length determined from LF) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DEG |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DEGH |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DEGI |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DEGJ |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TRDV |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |S| LH |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | H (length determined from LH) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |S| LK |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | K (length determined from LK) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LQ |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Q (length determined from LQ) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | A (length determined from LA) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ALTA |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LB |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | B (length determined from LB) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LC |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | C (length determined from LC) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LG |
+
+
+R. Schroeppel, et al [Page 4]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | G (length determined from LG) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | LY |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Y (length determined from LY) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ SMFMTABZ is a flags octet as follows:
+
+ S = 1 indicates that the remaining 7 bits of the octet selects
+ one of 128 predefined choices of finite field, element
+ representation, elliptic curve, and signature parameters.
+ MFMTABZ are omitted, as are all parameters from LP through G.
+ LY and Y are retained.
+
+ If S = 0, the remaining parameters are as in the picture and
+ described below.
+
+ M determines the type of field underlying the elliptic curve.
+
+ M = 0 if the field is a GF[2^N] field;
+
+ M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
+
+ FMT is a three bit field describing the format of the field
+ representation.
+
+ FMT = 0 for a (mod P) field.
+ > 0 for an extension field, either GF[2^D] or GF[P^D].
+ The degree D of the extension, and the field polynomial
+ must be specified. The field polynomial is always monic
+ (leading coefficient 1.)
+
+ FMT = 1 The field polynomial is given explicitly; D is implied.
+
+ If FMT >=2, the degree D is given explicitly.
+
+ = 2 The field polynomial is implicit.
+ = 3 The field polynomial is a binomial. P>2.
+ = 4 The field polynomial is a trinomial.
+ = 5 The field polynomial is the quotient of a trinomial by a
+ short polynomial. P=2.
+ = 6 The field polynomial is a pentanomial. P=2.
+
+ Flags A and B apply to the elliptic curve parameters.
+
+
+
+
+
+
+R. Schroeppel, et al [Page 5]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ A = 1 When P>=5, the curve parameter A is negated. If P=2, then
+ A=1 indicates that the A parameter is special. See the
+ ALTA parameter below, following A. The combination A=1,
+ P=3 is forbidden.
+
+ B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
+ then B=1 indicates an alternate elliptic curve equation is
+ used. When P=2 and B=1, an additional curve parameter C
+ is present.
+
+ The Z bit SHOULD be set to zero on creation of an RR and MUST be
+ ignored when processing an RR (when S=0).
+
+ Most of the remaining parameters are present in some formats and
+ absent in others. The presence or absence of a parameter is
+ determined entirely by the flags. When a parameter occurs, it is in
+ the order defined by the picture.
+
+ Of the remaining parameters, PFHKQABCGY are variable length. When
+ present, each is preceded by a one-octet length field as shown in the
+ diagram above. The length field does not include itself. The length
+ field may have values from 0 through 110. The parameter length in
+ octets is determined by a conditional formula: If LL<=64, the
+ parameter length is LL. If LL>64, the parameter length is 16 times
+ (LL-60). In some cases, a parameter value of 0 is sensible, and MAY
+ be represented by an LL value of 0, with the data field omitted. A
+ length value of 0 represents a parameter value of 0, not an absent
+ parameter. (The data portion occupies 0 space.) There is no
+ requirement that a parameter be represented in the minimum number of
+ octets; high-order 0 octets are allowed at the front end. Parameters
+ are always right adjusted, in a field of length defined by LL. The
+ octet-order is always most-significant first, least-significant last.
+ The parameters H and K may have an optional sign bit stored in the
+ unused high-order bit of their length fields.
+
+ LP defines the length of the prime P. P must be an odd prime. The
+ parameters LP,P are present if and only if the flag M=1. If M=0, the
+ prime is 2.
+
+ LF,F define an explicit field polynomial. This parameter pair is
+ present only when FMT = 1. The length of a polynomial coefficient is
+ ceiling(log2 P) bits. Coefficients are in the numerical range
+ [0,P-1]. The coefficients are packed into fixed-width fields, from
+ higher order to lower order. All coefficients must be present,
+ including any 0s and also the leading coefficient (which is required
+ to be 1). The coefficients are right justified into the octet string
+ of length specified by LF, with the low-order "constant" coefficient
+ at the right end. As a concession to storage efficiency, the higher
+ order bits of the leading coefficient may be elided, discarding high-
+ order 0 octets and reducing LF. The degree is calculated by
+
+
+R. Schroeppel, et al [Page 6]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ determining the bit position of the left most 1-bit in the F data
+ (counting the right most bit as position 0), and dividing by
+ ceiling(log2 P). The division must be exact, with no remainder. In
+ this format, all of the other degree and field parameters are
+ omitted. The next parameters will be LQ,Q.
+
+ If FMT>=2, the degree of the field extension is specified explicitly,
+ usually along with other parameters to define the field polynomial.
+
+ DEG is a two octet field that defines the degree of the field
+ extension. The finite field will have P^DEG elements. DEG is
+ present when FMT>=2.
+
+ When FMT=2, the field polynomial is specified implicitly. No other
+ parameters are required to define the field; the next parameters
+ present will be the LQ,Q pair. The implicit field poynomial is the
+ lexicographically smallest irreducible (mod P) polynomial of the
+ correct degree. The ordering of polynomials is by highest-degree
+ coefficients first -- the leading coefficient 1 is most important,
+ and the constant term is least important. Coefficients are ordered
+ by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
+ degree D is X^D (which is not irreducible). The next is X^D+1, which
+ is sometimes irreducible, followed by X^D-1, which isn't. Assuming
+ odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
+ X, X^D + X + 1, X^D + X - 1, etc.
+
+ When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
+ odd. The polynomial is determined by the degree and the low order
+ term K. Of all the field parameters, only the LK,K parameters are
+ present. The high-order bit of the LK octet stores on optional sign
+ for K; if the sign bit is present, the field polynomial is X^DEG - K.
+
+ When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
+ K. When P=2, the H and K parameters are implicitly 1, and are
+ omitted from the representation. Only DEG and DEGH are present; the
+ next parameters are LQ,Q. When P>2, then LH,H and LK,K are
+ specified. Either or both of LH, LK may contain a sign bit for its
+ parameter.
+
+ When FMT=5, then P=2 (only). The field polynomial is the exact
+ quotient of a trinomial divided by a small polynomial, the trinomial
+ divisor. The small polynomial is right-adjusted in the two octet
+ field TRDV. DEG specifies the degree of the field. The degree of
+ TRDV is calculated from the position of the high-order 1 bit. The
+ trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
+ DEGH is 0, the middle term is omitted from the trinomial. The
+ quotient must be exact, with no remainder.
+
+ When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
+ with the degrees of the middle terms given by the three 2-octet
+
+
+R. Schroeppel, et al [Page 7]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
+ X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
+ > DEGJ > 0.
+
+ DEGH, DEGI, DEGJ are two-octet fields that define the degree of
+ a term in a field polynomial. DEGH is present when FMT = 4,
+ 5, or 6. DEGI and DEGJ are present only when FMT = 6.
+
+ TRDV is a two-octet right-adjusted binary polynomial of degree <
+ 16. It is present only for FMT=5.
+
+ LH and H define the H parameter, present only when FMT=4 and P
+ is odd. The high bit of LH is an optional sign bit for H.
+
+ LK and K define the K parameter, present when FMT = 3 or 4, and
+ P is odd. The high bit of LK is an optional sign bit for K.
+
+ The remaining parameters are concerned with the elliptic curve and
+ the signature algorithm.
+
+ LQ defines the length of the prime Q. Q is a prime > 2^159.
+
+ In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
+ member of the pair is an element from the finite field defined
+ earlier. The length field defines a long octet string. Field
+ elements are represented as (mod P) polynomials of degree < DEG, with
+ DEG or fewer coefficients. The coefficients are stored from left to
+ right, higher degree to lower, with the constant term last. The
+ coefficients are represented as integers in the range [0,P-1]. Each
+ coefficient is allocated an area of ceiling(log2 P) bits. The field
+ representation is right-justified; the "constant term" of the field
+ element ends at the right most bit. The coefficients are fitted
+ adjacently without regard for octet boundaries. (Example: if P=5,
+ three bits are used for each coefficient. If the field is GF[5^75],
+ then 225 bits are required for the coefficients, and as many as 29
+ octets may be needed in the data area. Fewer octets may be used if
+ some high-order coefficients are 0.) If a flag requires a field
+ element to be negated, each non-zero coefficient K is replaced with
+ P-K. To save space, 0 bits may be removed from the left end of the
+ element representation, and the length field reduced appropriately.
+ This would normally only happen with A,B,C, because the designer
+ chose curve parameters with some high-order 0 coefficients or bits.
+
+ If the finite field is simply (mod P), then the field elements are
+ simply numbers (mod P), in the usual right-justified notation. If
+ the finite field is GF[2^D], the field elements are the usual right-
+ justified polynomial basis representation.
+
+
+
+
+
+R. Schroeppel, et al [Page 8]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ LA,A is the first parameter of the elliptic curve equation.
+ When P>=5, the flag A = 1 indicates A should be negated (mod
+ P). When P=2 (indicated by the flag M=0), the flag A = 1
+ indicates that the parameter pair LA,A is replaced by the two
+ octet parameter ALTA. In this case, the parameter A in the
+ curve equation is x^ALTA, where x is the field generator.
+ Parameter A often has the value 0, which may be indicated by
+ LA=0 (with no A data field), and sometimes A is 1, which may
+ be represented with LA=1 and a data field of 1, or by setting
+ the A flag and using an ALTA value of 0.
+
+ LB,B is the second parameter of the elliptic curve equation.
+ When P>=5, the flag B = 1 indicates B should be negated (mod
+ P). When P=2 or 3, the flag B selects an alternate curve
+ equation.
+
+ LC,C is the third parameter of the elliptic curve equation,
+ present only when P=2 (indicated by flag M=0) and flag B=1.
+
+ LG,G defines a point on the curve, of order Q. The W-coordinate
+ of the curve point is given explicitly; the Z-coordinate is
+ implicit.
+
+ LY,Y is the user's public signing key, another curve point of
+ order Q. The W-coordinate is given explicitly; the Z-
+ coordinate is implicit. The LY,Y parameter pair is always
+ present.
+
+
+
+3. The Elliptic Curve Equation
+
+ (The coordinates of an elliptic curve point are named W,Z instead of
+ the more usual X,Y to avoid confusion with the Y parameter of the
+ signing key.)
+
+ The elliptic curve equation is determined by the flag octet, together
+ with information about the prime P. The primes 2 and 3 are special;
+ all other primes are treated identically.
+
+ If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
+ + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
+ If A and/or B is negative (i.e., in the range from P/2 to P), and
+ P>=5, space may be saved by putting the sign bit(s) in the A and B
+ bits of the flags octet, and the magnitude(s) in the parameter
+ fields.
+
+ If M=1 and P=3, the B flag has a different meaning: it specifies an
+ alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
+ the right-hand-side is different. When P=3, this equation is more
+
+
+R. Schroeppel, et al [Page 9]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ commonly used.
+
+ If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
+ A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
+ parameter can often be 0 or 1, or be chosen as a single-1-bit value.
+ The flag B is used to select an alternate curve equation, Z^2 + C*Z =
+ W^3 + A*W + B. This is the only time that the C parameter is used.
+
+
+
+4. How do I Compute Q, G, and Y?
+
+ The number of points on the curve is the number of solutions to the
+ curve equation, + 1 (for the "point at infinity"). The prime Q must
+ divide the number of points. Usually the curve is chosen first, then
+ the number of points is determined with Schoof's algorithm. This
+ number is factored, and if it has a large prime divisor, that number
+ is taken as Q.
+
+ G must be a point of order Q on the curve, satisfying the equation
+
+ Q * G = the point at infinity (on the elliptic curve)
+
+ G may be chosen by selecting a random [RFC 1750] curve point, and
+ multiplying it by (number-of-points-on-curve/Q). G must not itself
+ be the "point at infinity"; in this astronomically unlikely event, a
+ new random curve point is recalculated.
+
+ G is specified by giving its W-coordinate. The Z-coordinate is
+ calculated from the curve equation. In general, there will be two
+ possible Z values. The rule is to choose the "positive" value.
+
+ In the (mod P) case, the two possible Z values sum to P. The smaller
+ value is less than P/2; it is used in subsequent calculations. In
+ GF[P^D] fields, the highest-degree non-zero coefficient of the field
+ element Z is used; it is chosen to be less than P/2.
+
+ In the GF[2^N] case, the two possible Z values xor to W (or to the
+ parameter C with the alternate curve equation). The numerically
+ smaller Z value (the one which does not contain the highest-order 1
+ bit of W (or C)) is used in subsequent calculations.
+
+ Y is specified by giving the W-coordinate of the user's public
+ signature key. The Z-coordinate value is determined from the curve
+ equation. As with G, there are two possible Z values; the same rule
+ is followed for choosing which Z to use.
+
+
+
+
+
+
+R. Schroeppel, et al [Page 10]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ During the key generation process, a random [RFC 1750] 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
+
+ Y = X * G (as points on the elliptic curve)
+
+ If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
+ in the (mod P) case, or the high-order non-zero coefficient of Z >
+ P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
+ GF[2^N] case), then X must be replaced with Q-X. This will
+ correspond to the correct Z-coordinate.
+
+
+
+5. Elliptic Curve SIG Resource Records
+
+ The signature portion of an RR RDATA area when using the EC
+ algorithm, for example in the RRSIG and SIG [RFC records] RRs is
+ shown below.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | R, (length determined from LQ) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | S, (length determined from LQ) .../
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ R and S are integers (mod Q). Their length is specified by the LQ
+ field of the corresponding KEY RR and can also be calculated from the
+ SIG RR's RDLENGTH. They are right justified, high-order-octet first.
+ The same conditional formula for calculating the length from LQ is
+ used as for all the other length fields above.
+
+ The data signed is determined as specified in [RFC 2535]. Then the
+ following steps are taken where Q, P, G, and Y are as specified in
+ the public key [Schneier]:
+
+ hash = SHA-1 ( data )
+
+ Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two
+ different messages with the same K. K should be chosen from a
+ very large space: If an opponent learns a K value for a single
+ signature, the user's signing key is compromised, and a forger
+ can sign arbitrary messages. There is no harm in signing the
+ same message multiple times with the same key or different
+ keys.)
+
+ R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
+
+
+R. Schroeppel, et al [Page 11]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ as an integer, and reduced (mod Q). (R must not be 0. In
+ this astronomically unlikely event, generate a new random K
+ and recalculate R.)
+
+ S = ( K^(-1) * (hash + X*R) ) mod Q.
+
+ S must not be 0. In this astronomically unlikely event, generate a
+ new random K and recalculate R and S.
+
+ If S > Q/2, set S = Q - S.
+
+ The pair (R,S) is the signature.
+
+ Another party verifies the signature as follows:
+
+ Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
+ valid EC sigature.
+
+ hash = SHA-1 ( data )
+
+ Sinv = S^(-1) mod Q.
+
+ U1 = (hash * Sinv) mod Q.
+
+ U2 = (R * Sinv) mod Q.
+
+ (U1 * G + U2 * Y) is computed on the elliptic curve.
+
+ V = (the W-coordinate of this point) interpreted as an integer
+ and reduced (mod Q).
+
+ The signature is valid if V = R.
+
+ The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
+ (R,Q-S) would be valid signatures for the same data. Note that a
+ signature that is valid for hash(data) is also valid for
+ hash(data)+Q or hash(data)-Q, if these happen to fall in the range
+ [0,2^160-1]. It's believed to be computationally infeasible to
+ find data that hashes to an assigned value, so this is only a
+ cosmetic blemish. The blemish can be eliminated by using Q >
+ 2^160, at the cost of having slightly longer signatures, 42 octets
+ instead of 40.
+
+ We must specify how a field-element E ("the W-coordinate") is to be
+ interpreted as an integer. The field-element E is regarded as a
+ radix-P integer, with the digits being the coefficients in the
+ polynomial basis representation of E. The digits are in the ragne
+ [0,P-1]. In the two most common cases, this reduces to "the
+ obvious thing". In the (mod P) case, E is simply a residue mod P,
+ and is taken as an integer in the range [0,P-1]. In the GF[2^D]
+
+
+R. Schroeppel, et al [Page 12]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ case, E is in the D-bit polynomial basis representation, and is
+ simply taken as an integer in the range [0,(2^D)-1]. For other
+ fields GF[P^D], it's necessary to do some radix conversion
+ arithmetic.
+
+
+
+ 6. Performance Considerations
+
+ Elliptic curve signatures use smaller moduli or field sizes than
+ RSA and DSA. Creation of a curve is slow, but not done very often.
+ Key generation is faster than RSA or DSA.
+
+ DNS implementations have been optimized for small transfers,
+ typically less than 512 octets including DNS overhead. Larger
+ transfers will perform correctly and and extensions have been
+ standardized to make larger transfers more efficient [RFC 2671].
+ However, it is still advisable at this time to make reasonable
+ efforts to minimize the size of RR sets stored within the DNS
+ consistent with adequate security.
+
+
+
+ 7. 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.
+
+ Some specific key generation considerations are given in the body
+ of this document.
+
+
+
+ 8. IANA Considerations
+
+ The key and signature data structures defined herein correspond to
+ the value 4 in the Algorithm number field of the IANA registry
+
+ Assignment of meaning to the remaining ECC data flag bits or to
+ values of ECC fields outside the ranges for which meaning in
+ defined in this document requires an IETF consensus as defined in
+ [RFC 2434].
+
+
+
+
+
+R. Schroeppel, et al [Page 13]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ Copyright and Disclaimer
+
+ Copyright (C) The Internet Society 2005. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al [Page 14]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ Informational References
+
+ [RFC 1034] - P. Mockapetris, "Domain names - concepts and
+ facilities", 11/01/1987.
+
+ [RFC 1035] - P. Mockapetris, "Domain names - implementation and
+ specification", 11/01/1987.
+
+ [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
+ 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.
+
+ [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106, RFC 4086, June
+ 2005.
+
+ [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
+ Algorithms, and Source Code in C", 1996, John Wiley and Sons
+
+ [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
+ Cryptosystems", 1993 Kluwer.
+
+ [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
+ Curves", 1986, Springer Graduate Texts in mathematics #106.
+
+
+
+ Normative Refrences
+
+ [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", March 1997.
+
+ [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", October 1998.
+
+ [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
+ S. Rose, "Resource Records for the DNS Security Extensions", RFC
+ 4034, March 2005.
+
+
+
+
+
+
+
+R. Schroeppel, et al [Page 15]
+
+
+INTERNET-DRAFT ECC Keys in the DNS
+
+
+ Author's Addresses
+
+ Rich Schroeppel
+ 500 S. Maple Drive
+ Woodland Hills, UT 84653 USA
+
+ Telephone: +1-505-844-9079(w)
+ Email: rschroe@sandia.gov
+
+
+ Donald E. Eastlake 3rd
+ Motorola Laboratories
+ 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 January 2006.
+
+ Its file name is draft-ietf-dnsext-ecc-key-07.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+R. Schroeppel, et al [Page 16]
+
diff --git a/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/doc/draft/draft-ietf-dnsext-interop3597-02.txt
new file mode 100644
index 0000000..160afc3
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-interop3597-02.txt
@@ -0,0 +1,334 @@
+DNS Extensions Working Group J. Schlyter
+Internet-Draft May 19, 2005
+Expires: November 20, 2005
+
+
+ RFC 3597 Interoperability Report
+ draft-ietf-dnsext-interop3597-02.txt
+
+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 November 20, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This memo documents the result from the RFC 3597 (Handling of Unknown
+ DNS Resource Record Types) interoperability testing.
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires November 20, 2005 [Page 1]
+
+Internet-Draft RFC 3597 Interoperability Report May 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3
+ 3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3
+ 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4
+ 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4
+ 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
+ A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5
+ Intellectual Property and Copyright Statements . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires November 20, 2005 [Page 2]
+
+Internet-Draft RFC 3597 Interoperability Report May 2005
+
+
+1. Introduction
+
+ This memo documents the result from the RFC 3597 (Handling of Unknown
+ DNS Resource Record Types) interoperability testing. The test was
+ performed during June and July 2004 by request of the IETF DNS
+ Extensions Working Group.
+
+2. Implementations
+
+ The following is a list, in alphabetic order, of implementations
+ tested for compliance with RFC 3597:
+
+ DNSJava 1.6.4
+ ISC BIND 8.4.5
+ ISC BIND 9.3.0
+ NSD 2.1.1
+ Net::DNS 0.47 patchlevel 1
+ Nominum ANS 2.2.1.0.d
+
+ These implementations covers the following functions (number of
+ implementations tested for each function in paranthesis):
+
+ Authoritative Name Servers (4)
+ Full Recursive Resolver (2)
+ Stub Resolver (4)
+ DNSSEC Zone Signers (2)
+
+ All listed implementations are genetically different.
+
+3. Tests
+
+ The following tests was been performed to validate compliance with
+ RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
+ and 5 ("Text Representation").
+
+3.1 Authoritative Primary Name Server
+
+ The test zone data (Appendix A) was loaded into the name server
+ implementation and the server was queried for the loaded information.
+
+3.2 Authoritative Secondary Name Server
+
+ The test zone data (Appendix A) was transferred using AXFR from
+ another name server implementation and the server was queried for the
+ transferred information.
+
+
+
+
+
+
+Schlyter Expires November 20, 2005 [Page 3]
+
+Internet-Draft RFC 3597 Interoperability Report May 2005
+
+
+3.3 Full Recursive Resolver
+
+ A recursive resolver was queried for resource records from a domain
+ with the test zone data (Appendix A).
+
+3.4 Stub Resolver
+
+ A stub resolver was used to query resource records from a domain with
+ the test zone data (Appendix A).
+
+3.5 DNSSEC Signer
+
+ A DNSSEC signer was used to sign a zone with test zone data
+ (Appendix A).
+
+4. Problems found
+
+ Two implementations had problems with text presentation of zero
+ length RDATA.
+
+ One implementation had problems with text presentation of RR type
+ code and classes >= 4096.
+
+ Bug reports were filed for problems found.
+
+5. Summary
+
+ Unknown type codes works in the tested authoritative servers,
+ recursive resolvers and stub clients.
+
+ No changes are needed to advance RFC 3597 to draft standard.
+
+6. Normative References
+
+ [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+ Types", RFC 3597, September 2003.
+
+
+Author's Address
+
+ Jakob Schlyter
+
+ Email: jakob@rfc.se
+
+
+
+
+
+
+
+
+Schlyter Expires November 20, 2005 [Page 4]
+
+Internet-Draft RFC 3597 Interoperability Report May 2005
+
+
+Appendix A. Test zone data
+
+ ; A-record encoded as TYPE1
+ a TYPE1 \# 4 7f000001
+ a TYPE1 192.0.2.1
+ a A \# 4 7f000002
+
+ ; draft-ietf-secsh-dns-05.txt
+ sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
+
+ ; bogus test record (from RFC 3597)
+ type731 TYPE731 \# 6 abcd (
+ ef 01 23 45 )
+
+ ; zero length RDATA (from RFC 3597)
+ type62347 TYPE62347 \# 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter Expires November 20, 2005 [Page 5]
+
+Internet-Draft RFC 3597 Interoperability Report May 2005
+
+
+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 (2005). 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.
+
+
+
+
+Schlyter Expires November 20, 2005 [Page 6]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
new file mode 100644
index 0000000..6bffb70
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
@@ -0,0 +1,560 @@
+
+DNS Extensions O. Kolkman
+Internet-Draft RIPE NCC
+Expires: June 17, 2004 J. Schlyter
+
+ E. Lewis
+ ARIN
+ December 18, 2003
+
+
+ DNSKEY RR Secure Entry Point Flag
+ draft-ietf-dnsext-keyrr-key-signing-flag-12
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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 17, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ With the Delegation Signer (DS) resource record the concept of a
+ public key acting as a secure entry point has been introduced. During
+ exchanges of public keys with the parent there is a need to
+ differentiate secure entry point keys from other public keys in the
+ DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is
+ defined to indicate that DNSKEY is to be used as a secure entry
+ point. The flag bit is intended to assist in operational procedures
+ to correctly generate DS resource records, or to indicate what
+ DNSKEYs are intended for static configuration. The flag bit is not to
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 1]
+
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
+
+
+ be used in the DNS verification protocol. This document updates RFC
+ 2535 and RFC 3445.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4
+ 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5
+ 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+ 7. Internationalization Considerations . . . . . . . . . . . . . . 6
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Normative References . . . . . . . . . . . . . . . . . . . . . . 7
+ Informative References . . . . . . . . . . . . . . . . . . . . . 7
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
+ Intellectual Property and Copyright Statements . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 2]
+
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
+
+
+1. Introduction
+
+ "All keys are equal but some keys are more equal than others" [6]
+
+ With the definition of the Delegation Signer Resource Record (DS RR)
+ [5] it has become important to differentiate between the keys in the
+ DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
+ other keys in the DNSKEY RR set. We refer to these public keys as
+ Secure Entry Point (SEP) keys. A SEP key either used to generate a
+ DS RR or is distributed to resolvers that use the key as the root of
+ a trusted subtree[3].
+
+ In early deployment tests, the use of two (kinds of) key pairs for
+ each zone has been prevalent. For one kind of key pair the private
+ key is used to sign just the zone's DNSKEY resource record (RR) set.
+ Its public key is intended to be referenced by a DS RR at the parent
+ or configured statically in a resolver. The private key of the other
+ kind of key pair is used to sign the rest of the zone's data sets.
+ The former key pair is called a key-signing key (KSK) and the latter
+ is called a zone-signing key (ZSK). In practice there have been
+ usually one of each kind of key pair, but there will be multiples of
+ each at times.
+
+ It should be noted that division of keys pairs into KSK's and ZSK's
+ is not mandatory in any definition of DNSSEC, not even with the
+ introduction of the DS RR. But, in testing, this distinction has
+ been helpful when designing key roll over (key super-cession)
+ schemes. Given that the distinction has proven helpful, the labels
+ KSK and ZSK have begun to stick.
+
+ There is a need to differentiate the public keys for the key pairs
+ that are used for key signing from keys that are not used key signing
+ (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
+ be sent for generating DS RRs, which DNSKEYs are to be distributed to
+ resolvers, and which keys are fed to the signer application at the
+ appropriate time.
+
+ In other words, the SEP bit provides an in-band method to communicate
+ a DNSKEY RR's intended use to third parties. As an example we present
+ 3 use cases in which the bit is useful:
+
+ The parent is a registry, the parent and the child use secured DNS
+ queries and responses, with a preexisting trust-relation, or plain
+ DNS over a secured channel to exchange the child's DNSKEY RR
+ sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
+ the SEP bit can be used to isolate the DNSKEYs for which a DS RR
+ needs to be created.
+
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 3]
+
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
+
+
+ An administrator has configured a DNSKEY as root for a trusted
+ subtree into security aware resolver. Using a special purpose tool
+ that queries for the KEY RRs from that domain's apex, the
+ administrator will be able to notice the roll over of the trusted
+ anchor by a change of the subset of KEY RRs with the DS flag set.
+
+ A signer might use the SEP bit on the public key to determine
+ which private key to use to exclusively sign the DNSKEY RRset and
+ which private key to use to sign the other RRsets in the zone.
+
+ As demonstrated in the above examples it is important to be able to
+ differentiate the SEP keys from the other keys in a DNSKEY RR set in
+ the flow between signer and (parental) key-collector and in the flow
+ between the signer and the resolver configuration. The SEP flag is to
+ be of no interest to the flow between the verifier and the
+ authoritative data store.
+
+ The reason for the term "SEP" is a result of the observation that the
+ distinction between KSK and ZSK key pairs is made by the signer, a
+ key pair could be used as both a KSK and a ZSK at the same time. To
+ be clear, the term SEP was coined to lessen the confusion caused by
+ the overlap. ( Once this label was applied, it had the side effect of
+ removing the temptation to have both a KSK flag bit and a ZSK flag
+ bit.)
+
+ The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
+ "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
+ interpreted as described in RFC2119 [1].
+
+2. The Secure Entry Point (SEP) Flag
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | flags |S| protocol | algorithm |
+ | |E| | |
+ | |P| | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | /
+ / public key /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ DNSKEY RR Format
+
+
+
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 4]
+
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
+
+
+ This document assigns the 15'th bit in the flags field as the secure
+ entry point (SEP) bit. If the the bit is set to 1 the key is
+ intended to be used as secure entry point key. One SHOULD NOT assign
+ special meaning to the key if the bit is set to 0. Operators can
+ recognize the secure entry point key by the even or odd-ness of the
+ decimal representation of the flag field.
+
+3. DNSSEC Protocol Changes
+
+ The bit MUST NOT be used during the resolving and verification
+ process. The SEP flag is only used to provide a hint about the
+ different administrative properties of the key and therefore the use
+ of the SEP flag does not change the DNS resolution protocol or the
+ resolution process.
+
+4. Operational Guidelines
+
+ The SEP bit is set by the key-pair-generator and MAY be used by the
+ zone signer to decide whether the public part of the key pair is to
+ be prepared for input to a DS RR generation function. The SEP bit is
+ recommended to be set (to 1) whenever the public key of the key pair
+ will be distributed to the parent zone to build the authentication
+ chain or if the public key is to be distributed for static
+ configuration in verifiers.
+
+ When a key pair is created, the operator needs to indicate whether
+ the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within
+ the data that is used to compute the 'key tag field' in the SIG RR,
+ changing the SEP bit will change the identity of the key within DNS.
+ In other words, once a key is used to generate signatures, the
+ setting of the SEP bit is to remain constant. If not, a verifier will
+ not be able to find the relevant KEY RR.
+
+ When signing a zone, it is intended that the key(s) with the SEP bit
+ set (if such keys exist) are used to sign the KEY RR set of the zone.
+ The same key can be used to sign the rest of the zone data too. It
+ is conceivable that not all keys with a SEP bit set will sign the
+ DNSKEY RR set, such keys might be pending retirement or not yet in
+ use.
+
+ When verifying a RR set, the SEP bit is not intended to play a role.
+ How the key is used by the verifier is not intended to be a
+ consideration at key creation time.
+
+ Although the SEP flag provides a hint on which public key is to be
+ used as trusted root, administrators can choose to ignore the fact
+ that a DNSKEY has its SEP bit set or not when configuring a trusted
+ root for their resolvers.
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 5]
+
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
+
+
+ Using the SEP flag a key roll over can be automated. The parent can
+ use an existing trust relation to verify DNSKEY RR sets in which a
+ new DNSKEY RR with the SEP flag appears.
+
+5. Security Considerations
+
+ As stated in Section 3 the flag is not to be used in the resolution
+ protocol or to determine the security status of a key. The flag is to
+ be used for administrative purposes only.
+
+ No trust in a key should be inferred from this flag - trust MUST be
+ inferred from an existing chain of trust or an out-of-band exchange.
+
+ Since this flag might be used for automating public key exchanges, we
+ think the following consideration is in place.
+
+ Automated mechanisms for roll over of the DS RR might be vulnerable
+ to a class of replay attacks. This might happen after a public key
+ exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
+ SEP flag set, is sent to the parent. The parent verifies the DNSKEY
+ RR set with the existing trust relation and creates the new DS RR
+ from the DNSKEY RR that the current DS RR is not pointing to. This
+ key exchange might be replayed. Parents are encouraged to implement a
+ replay defense. A simple defense can be based on a registry of keys
+ that have been used to generate DS RRs during the most recent roll
+ over. These same considerations apply to entities that configure keys
+ in resolvers.
+
+6. IANA Considerations
+
+ The flag bits in the DNSKEY RR are assigned by IETF consensus and
+ registered in the DNSKEY Flags registry (created by [4]). This
+ document assigns the 15th bit in the DNSKEY RR as the Secure Entry
+ Point (SEP) bit.
+
+7. Internationalization Considerations
+
+ Although SEP is a popular acronym in many different languages, there
+ are no internationalization considerations.
+
+8. Acknowledgments
+
+ The ideas documented in this document are inspired by communications
+ we had with numerous people and ideas published by other folk. Among
+ others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
+ Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
+ have contributed ideas and provided feedback.
+
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 6]
+
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
+
+
+ This document saw the light during a workshop on DNSSEC operations
+ hosted by USC/ISI in August 2002.
+
+Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [3] Lewis, E., "DNS Security Extension Clarification on Zone
+ Status", RFC 3090, March 2001.
+
+ [4] Weiler, S., "Legacy Resolver Compatibility for Delegation
+ Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
+ in progress), October 2003.
+
+Informative References
+
+ [5] Gudmundsson, O., "Delegation Signer Resource Record",
+ draft-ietf-dnsext-delegation-signer-15 (work in progress), June
+ 2003.
+
+ [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
+ Story", ISBN 0151002177 (50th anniversary edition), April 1996.
+
+
+Authors' Addresses
+
+ Olaf M. Kolkman
+ RIPE NCC
+ Singel 256
+ Amsterdam 1016 AB
+ NL
+
+ Phone: +31 20 535 4444
+ EMail: olaf@ripe.net
+ URI: http://www.ripe.net/
+
+
+ Jakob Schlyter
+ Karl Gustavsgatan 15
+ Goteborg SE-411 25
+ Sweden
+
+ EMail: jakob@schlyter.se
+
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 7]
+
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
+
+
+ Edward P. Lewis
+ ARIN
+ 3635 Concorde Parkway Suite 200
+ Chantilly, VA 20151
+ US
+
+ Phone: +1 703 227 9854
+ EMail: edlewis@arin.net
+ URI: http://www.arin.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 8]
+
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 9]
+
+Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
+
+
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al. Expires June 17, 2004 [Page 10]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-mdns-43.txt b/doc/draft/draft-ietf-dnsext-mdns-43.txt
new file mode 100644
index 0000000..5de6e85
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-mdns-43.txt
@@ -0,0 +1,1740 @@
+
+
+
+
+
+
+DNSEXT Working Group Bernard Aboba
+INTERNET-DRAFT Dave Thaler
+Category: Standards Track Levon Esibov
+<draft-ietf-dnsext-mdns-43.txt> Microsoft Corporation
+29 August 2005
+
+ 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 March 15, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society 2005.
+
+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 29 August 2005
+
+
+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 ............................. 6
+ 2.2 Sender Behavior ................................. 9
+ 2.3 Responder Behavior .............................. 10
+ 2.4 Unicast Queries and Responses ................... 12
+ 2.5 Off-link Detection .............................. 13
+ 2.6 Responder Responsibilities ...................... 13
+ 2.7 Retransmission and Jitter ....................... 14
+ 2.8 DNS TTL ......................................... 15
+ 2.9 Use of the Authority and Additional Sections .... 15
+3. Usage model ........................................... 16
+ 3.1 LLMNR Configuration ............................. 17
+4. Conflict Resolution ................................... 18
+ 4.1 Uniqueness Verification ......................... 19
+ 4.2 Conflict Detection and Defense .................. 20
+ 4.3 Considerations for Multiple Interfaces .......... 21
+ 4.4 API issues ...................................... 22
+5. Security Considerations ............................... 22
+ 5.1 Denial of Service ............................... 23
+ 5.2 Spoofing ...............,........................ 23
+ 5.3 Authentication .................................. 24
+ 5.4 Cache and Port Separation ....................... 25
+6. IANA considerations ................................... 25
+7. Constants ............................................. 25
+8. References ............................................ 25
+ 8.1 Normative References ............................ 25
+ 8.2 Informative References .......................... 26
+Acknowledgments .............................................. 27
+Authors' Addresses ........................................... 28
+Intellectual Property Statement .............................. 28
+Disclaimer of Validity ....................................... 29
+Copyright Statement .......................................... 29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 2]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+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.
+
+ The goal of LLMNR is to enable name resolution in scenarios in which
+ conventional DNS name resolution is not possible. Usage scenarios
+ (discussed in more detail in Section 3.1) include 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, as described
+ in Section 2.
+
+ 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.
+
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 3]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+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].
+
+1.2. Terminology
+
+ This document assumes familiarity with DNS terminology defined in
+ [RFC1035]. Other terminology used in this document includes:
+
+Positively Resolved
+ Responses with RCODE set to zero are referred to in this document
+ as "positively resolved".
+
+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 is a peer-to-peer name resolution protocol that is not intended
+ as a replacement for DNS. 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
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 4]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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].
+
+ 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.
+
+ By default, LLMNR queries MAY be sent only when 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, then LLMNR
+ SHOULD NOT be used as the primary name resolution mechanism,
+ although it MAY be used as a secondary name resolution
+ mechanism. A dual stack host SHOULD attempt to reach DNS
+ servers overall 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 inplies 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.
+
+ While these conditions are necessary for sending an LLMNR query, they
+ are not sufficient. While an LLMNR sender MAY send a query for any
+ name, it also MAY impose additional conditions on sending LLMNR
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 5]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ queries. For example, a sender configured with a DNS server MAY send
+ LLMNR queries only for unqualified names and for fully qualified
+ domain names within configured zones.
+
+ A typical sequence of events for LLMNR usage is as follows:
+
+ [a] DNS servers are not configured or attempts to resolve the
+ name via DNS have failed, after exhausting the searchlist.
+ Also, the name to be queried satisfies the restrictions
+ imposed by the implementation.
+
+ [b] An LLMNR sender sends an LLMNR query to the link-scope
+ multicast address(es), unless a unicast query is indicated,
+ as specified in Section 2.4.
+
+ [c] A responder responds to this query only if it is authoritative
+ for the domain 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.
+
+ [d] 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:
+
+
+
+
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 6]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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:
+
+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.
+
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 7]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+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 discard the response and resend the LLMNR
+ query over TCP using the unicast address of the responder as the
+ destination address. 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.
+
+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.
+ Errors include those defined in [RFC2845], such as BADSIG(16),
+ BADKEY(17) and BADTIME(18).
+
+ 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
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 8]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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
+ 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
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 9]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ silently discarded.
+
+ 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.
+
+ 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
+ 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:
+
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 10]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
+ address(es) defined in Section 2, and on UDP and 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.
+
+[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.
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 11]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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
+ 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.
+
+ If TCP connection setup cannot be completed in order to send a
+ unicast TCP query, this is treated as a response that no records of
+ the specified type and class exist for the specified name (it is
+ treated the same as a response with RCODE=0 and an empty answer
+ section).
+
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 12]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+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.
+
+ 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 Apple Bonjour [Bonjour].
+
+ 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:
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 13]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ [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
+ 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,
+ while increasing the value of LLMNR_TIMEOUT exponentially. 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.
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 14]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ However, if the first response has the 'C' bit set, then the sender
+ SHOULD wait for LLMNR_TIMEOUT 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, so
+ that it only waits for LLMNR_TIMEOUT if no response has been
+ 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 and LLMNR_TIMEOUT estimation, 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
+ 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
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 15]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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.
+
+3. Usage Model
+
+ Since LLMNR is a secondary name resolution mechanism, its usage is in
+ part determined by the behavior of DNS implementations. This
+ document does not specify any changes to DNS resolver behavior, such
+ as searchlist processing or retransmission/failover policy. However,
+ robust DNS resolver implementations are more likely to avoid
+ unnecessary LLMNR queries.
+
+ As noted in [DNSPerf], even when DNS servers are configured, a
+ 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 backoff. [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
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 16]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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.
+
+3.1. LLMNR Configuration
+
+ 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
+ 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
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 17]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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
+ 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.
+
+
+
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 18]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+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
+ 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
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 19]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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
+ 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.
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 20]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+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.
+
+ ---------- ----------
+ | | | |
+ [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
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 21]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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.
+
+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
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 22]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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
+ 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)
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 23]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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.
+
+ Limiting the situations in which LLMNR queries are sent, as described
+ in Section 2, is the best protection against these attacks. 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 is only used as a name resolution mechanism of last resort.
+
+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. This makes it difficult to apply existing DNS security
+ mechanisms to LLMNR.
+
+ LLMNR does not support "delegated trust" (CD or AD bits). As a
+ result, unless LLMNR senders are DNSSEC aware, it is not feasible to
+ use DNSSEC [RFC4033] with LLMNR.
+
+ If authentication is desired, and a pre-arranged security
+ configuration is possible, then 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 responses, based on group keys.
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 24]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+[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.
+
+ Where these mechanisms cannot be supported, responses to LLMNR
+ queries may be unauthenticated.
+
+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.
+
+6. IANA Considerations
+
+ This specification creates one new name space: the reserved bits in
+ the LLMNR header. These are allocated by IETF Consensus, in
+ accordance with BCP 26 [RFC2434].
+
+ 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.
+
+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)
+
+8. References
+
+8.1. Normative References
+
+[RFC1035] Mockapetris, P., "Domain Names - Implementation and
+ Specification", RFC 1035, November 1987.
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 25]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+[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
+
+[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
+ (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
+ June 2005.
+
+[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.
+
+[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.
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 26]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+[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.
+
+[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.
+
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 27]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 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
+
+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.
+
+
+
+Aboba, Thaler & Esibov Standards Track [Page 28]
+
+
+
+
+
+INTERNET-DRAFT LLMNR 29 August 2005
+
+
+ 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 (2005). 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.
+
+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 29]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-nsec3-04.txt b/doc/draft/draft-ietf-dnsext-nsec3-04.txt
new file mode 100644
index 0000000..8c6c5b1
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-nsec3-04.txt
@@ -0,0 +1,2352 @@
+
+
+
+Network Working Group B. Laurie
+Internet-Draft G. Sisson
+Expires: August 5, 2006 R. Arends
+ Nominet
+ February 2006
+
+
+ DNSSEC Hash Authenticated Denial of Existence
+ draft-ietf-dnsext-nsec3-04
+
+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 August 5, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The DNS Security Extensions introduces the NSEC resource record for
+ authenticated denial of existence. This document introduces a new
+ resource record as an alternative to NSEC that provides measures
+ against zone enumeration and allows for gradual expansion of
+ delegation-centric zones.
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 1]
+
+Internet-Draft nsec3 February 2006
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. NSEC versus NSEC3 . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5
+ 3.1. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 6
+ 3.1.1. The Hash Function Field . . . . . . . . . . . . . . . 6
+ 3.1.2. The Opt-In Flag Field . . . . . . . . . . . . . . . . 7
+ 3.1.3. The Iterations Field . . . . . . . . . . . . . . . . . 8
+ 3.1.4. The Salt Length Field . . . . . . . . . . . . . . . . 8
+ 3.1.5. The Salt Field . . . . . . . . . . . . . . . . . . . . 8
+ 3.1.6. The Next Hashed Ownername Field . . . . . . . . . . . 9
+ 3.1.7. The Type Bit Maps Field . . . . . . . . . . . . . . . 9
+ 3.2. The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
+ 4. Creating Additional NSEC3 RRs for Empty Non-Terminals . . . . 11
+ 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 11
+ 6. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 11
+ 7. Responding to NSEC3 Queries . . . . . . . . . . . . . . . . . 12
+ 8. Special Considerations . . . . . . . . . . . . . . . . . . . . 13
+ 8.1. Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
+ 8.2. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 8.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 8.4. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
+ 8.4.1. Avoiding Hash Collisions during generation . . . . . . 16
+ 8.4.2. Second Preimage Requirement Analysis . . . . . . . . . 16
+ 8.4.3. Possible Hash Value Truncation Method . . . . . . . . 17
+ 8.4.4. Server Response to a Run-time Collision . . . . . . . 17
+ 8.4.5. Parameters that Cover the Zone . . . . . . . . . . . . 18
+ 9. Performance Considerations . . . . . . . . . . . . . . . . . . 18
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 22
+ Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
+ Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 22
+ Appendix B. Example Responses . . . . . . . . . . . . . . . . . . 27
+ B.1. answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ B.1.1. Authenticating the Example DNSKEY RRset . . . . . . . 29
+ B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
+ B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . . 32
+ B.3.1. No Data Error, Empty Non-Terminal . . . . . . . . . . 33
+ B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . . 34
+ B.5. Referral to Unsigned Zone using the Opt-In Flag . . . . . 35
+ B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 2]
+
+Internet-Draft nsec3 February 2006
+
+
+ B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
+ B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . . 39
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
+ Intellectual Property and Copyright Statements . . . . . . . . . . 42
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 3]
+
+Internet-Draft nsec3 February 2006
+
+
+1. Introduction
+
+1.1. Rationale
+
+ The DNS Security Extensions included the NSEC RR to provide
+ authenticated denial of existence. Though the NSEC RR meets the
+ requirements for authenticated denial of existence, it introduced a
+ side-effect in that the contents of a zone can be enumerated. This
+ property introduces undesired policy issues.
+
+ An enumerated zone can be used either directly as a source of
+ probable e-mail addresses for spam, or indirectly as a key for
+ multiple WHOIS queries to reveal registrant data which many
+ registries may be under strict legal obligations to protect. Many
+ registries therefore prohibit copying of their zone file; however the
+ use of NSEC RRs renders these policies unenforceable.
+
+ A second problem was the requirement that the existence of all record
+ types in a zone - including unsigned delegation points - must be
+ accounted for, despite the fact that unsigned delegation point
+ records are not signed. This requirement has a side-effect that the
+ overhead of signed zones is not related to the increase in security
+ of subzones. This requirement does not allow the zones' size to grow
+ in relation to the growth of signed subzones.
+
+ In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been
+ proposed as a measure against these side effects but at the time were
+ regarded as secondary over the need to have a stable DNSSEC
+ specification. With (draft-vixie-dnssec-ter) [14] a graceful
+ transition path to future enhancements is introduced, while current
+ DNSSEC deployment can continue. This document presents the NSEC3
+ Resource Record which mitigates these issues with the NSEC RR.
+
+ The reader is assumed to be familiar with the basic DNS and DNSSEC
+ concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
+ 4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
+ [6], RFC2181 [7] and RFC2308 [8].
+
+1.2. 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 [9].
+
+1.3. Terminology
+
+ The practice of discovering the contents of a zone, i.e. enumerating
+ the domains within a zone, is known as "zone enumeration". Zone
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 4]
+
+Internet-Draft nsec3 February 2006
+
+
+ enumeration was not practical prior to the introduction of DNSSEC.
+
+ In this document the term "original ownername" refers to a standard
+ ownername. Because this proposal uses the result of a hash function
+ over the original (unmodified) ownername, this result is referred to
+ as "hashed ownername".
+
+ "Hash order" means the order in which hashed ownernames are arranged
+ according to their numerical value, treating the leftmost (lowest
+ numbered) octet as the most significant octet. Note that this is the
+ same as the canonical ordering specified in RFC 4034 [4].
+
+ An "empty non-terminal" is a domain name that owns no resource
+ records but has subdomains that do.
+
+ The "closest encloser" of a (nonexistent) domain name is the longest
+ domain name, including empty non-terminals, that matches the
+ rightmost part of the nonexistent domain name.
+
+ "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
+ specified in RFC 3548bis [15].
+
+
+2. NSEC versus NSEC3
+
+ This document does NOT obsolete the NSEC record, but gives an
+ alternative for authenticated denial of existence. NSEC and NSEC3
+ RRs can not co-exist in a zone. See draft-vixie-dnssec-ter [14] for
+ a signaling mechanism to allow for graceful transition towards NSEC3.
+
+
+3. The NSEC3 Resource Record
+
+ The NSEC3 RR provides Authenticated Denial of Existence for DNS
+ Resource Record Sets.
+
+ The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
+ RR's original ownername. It includes the next hashed ownername in
+ the hash order of the zone. The complete set of NSEC3 RRs in a zone
+ indicates which RRsets exist for the original ownername of the RRset
+ and form a chain of hashed ownernames in the zone. This information
+ is used to provide authenticated denial of existence for DNS data, as
+ described in RFC 4035 [5]. To provide protection against zone
+ enumeration, the ownernames used in the NSEC3 RR are cryptographic
+ hashes of the original ownername prepended to the name of the zone.
+ The NSEC3 RR indicates which hash function is used to construct the
+ hash, which salt is used, and how many iterations of the hash
+ function are performed over the original ownername. The hashing
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 5]
+
+Internet-Draft nsec3 February 2006
+
+
+ technique is described fully in Section 5.
+
+ Hashed ownernames of unsigned delegations may be excluded from the
+ chain. An NSEC3 record which span covers the hash of an unsigned
+ delegation's ownername is referred to as an Opt-In NSEC3 record and
+ is indicated by the presence of a flag.
+
+ The ownername for the NSEC3 RR is the base32 encoding of the hashed
+ ownername prepended to the name of the zone..
+
+ The type value for the NSEC3 RR is XX.
+
+ The NSEC3 RR RDATA format is class independent and is described
+ below.
+
+ The class MUST be the same as the original ownername's class.
+
+ The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
+ field. This is in the spirit of negative caching [8].
+
+3.1. NSEC3 RDATA Wire Format
+
+ The RDATA of the NSEC3 RR is as shown below:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hash Function |O| Iterations |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Salt Length | Salt /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Next Hashed Ownername /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ / Type Bit Maps /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ "O" is the Opt-In Flag field.
+
+3.1.1. The Hash Function Field
+
+ The Hash Function field identifies the cryptographic hash function
+ used to construct the hash-value.
+
+ The values are as defined for the DS record (see RFC 3658 [10]).
+
+ On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
+ function value.
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 6]
+
+Internet-Draft nsec3 February 2006
+
+
+3.1.2. The Opt-In Flag Field
+
+ The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
+ delegations.
+
+ In DNSSEC, NS RRsets at delegation points are not signed, and may be
+ accompanied by a DS record. The security status of the subzone is
+ determined by the presence or absence of the DS RRset,
+ cryptographically proven by the NSEC record or the signed DS RRset.
+ The presence of the Opt-In flag expands this definition by allowing
+ insecure delegations to exist within an otherwise signed zone without
+ the corresponding NSEC3 record at the delegation's (hashed) owner
+ name. These delegations are proven insecure by using a covering
+ NSEC3 record.
+
+ Resolvers must be able to distinguish between NSEC3 records and
+ Opt-In NSEC3 records. This is accomplished by setting the Opt-In
+ flag of the NSEC3 records that cover (or potentially cover) insecure
+ delegation nodes.
+
+ An Opt-In NSEC3 record does not assert the existence or non-existence
+ of the insecure delegations that it covers. This allows for the
+ addition or removal of these delegations without recalculating or
+ resigning records in the NSEC3 chain. However, Opt-In NSEC3 records
+ do assert the (non)existence of other, authoritative RRsets.
+
+ An Opt-In NSEC3 record MAY have the same original owner name as an
+ insecure delegation. In this case, the delegation is proven insecure
+ by the lack of a DS bit in type map and the signed NSEC3 record does
+ assert the existence of the delegation.
+
+ Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
+ non-Opt-In NSEC3 records. If an NSEC3 record is not Opt-In, there
+ MUST NOT be any hashed ownernames of insecure delegations (nor any
+ other records) between it and the RRsets indicated by the 'Next
+ Hashed Ownername' in the NSEC3 RDATA. If it is Opt-In, there MUST
+ only be hashed ownernames of insecure delegations between it and the
+ next node indicated by the 'Next Hashed Ownername' in the NSEC3
+ RDATA.
+
+ In summary,
+ o An Opt-In NSEC3 type is identified by an Opt-In Flag field value
+ of 1.
+ o A non Opt-In NSEC3 type is identified by an Opt-In Flag field
+ value of 0.
+ and,
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 7]
+
+Internet-Draft nsec3 February 2006
+
+
+ o An Opt-In NSEC3 record does not assert the non-existence of a hash
+ ownername between its ownername and next hashed ownername,
+ although it does assert that any hashed name in this span MUST be
+ of an insecure delegation.
+ o An Opt-In NSEC3 record does assert the (non)existence of RRsets
+ with the same hashed owner name.
+
+3.1.3. The Iterations Field
+
+ The Iterations field defines the number of times the hash has been
+ iterated. More iterations results in greater resiliency of the hash
+ value against dictionary attacks, but at a higher cost for both the
+ server and resolver. See Section 5 for details of this field's use.
+
+ Iterations make an attack more costly by making the hash computation
+ more computationally intensive, e.g. by iterating the hash function a
+ number of times.
+
+ When generating a few hashes this performance loss will not be a
+ problem, as a validator can handle a delay of a few milliseconds.
+ But when doing a dictionary attack it will also multiply the attack
+ workload by a factor, which is a problem for the attacker.
+
+3.1.4. The Salt Length Field
+
+ The salt length field defines the length of the salt in octets.
+
+3.1.5. The Salt Field
+
+ The Salt field is not present when the Salt Length Field has a value
+ of 0.
+
+ The Salt field is appended to the original ownername before hashing
+ in order to defend against precalculated dictionary attacks. See
+ Section 5 for details on how the salt is used.
+
+ Salt is used to make dictionary attacks using precomputation more
+ costly. A dictionary can only be computed after the attacker has the
+ salt, hence a new salt means that the dictionary has to be
+ regenerated with the new salt.
+
+ There MUST be a complete set of NSEC3 records covering the entire
+ zone that use the same salt value. The requirement exists so that,
+ given any qname within a zone, at least one covering NSEC3 RRset may
+ be found. While it may be theoretically possible to produce a set of
+ NSEC3s that use different salts that cover the entire zone, it is
+ computationally infeasible to generate such a set. See Section 8.2
+ for further discussion.
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 8]
+
+Internet-Draft nsec3 February 2006
+
+
+ The salt value SHOULD be changed from time to time - this is to
+ prevent the use of a precomputed dictionary to reduce the cost of
+ enumeration.
+
+3.1.6. The Next Hashed Ownername Field
+
+ The Next Hashed Ownername field contains the next hashed ownername in
+ hash order. That is, given the set of all hashed owernames, the Next
+ Hashed Ownername contains the hash value that immediately follows the
+ owner hash value for the given NSEC3 record. The value of the Next
+ Hashed Ownername Field in the last NSEC3 record in the zone is the
+ same as the ownername of the first NSEC3 RR in the zone in hash
+ order.
+
+ Hashed ownernames of glue RRsets MUST NOT be listed in the Next
+ Hashed Ownername unless at least one authoritative RRset exists at
+ the same ownername. Hashed ownernames of delegation NS RRsets MUST
+ be listed if the Opt-In bit is clear.
+
+ Note that the Next Hashed Ownername field is not encoded, unlike the
+ NSEC3 RR's ownername. It is the unmodified binary hash value. It
+ does not include the name of the containing zone.
+
+ The length of this field is the length of the hash value produced by
+ the hash function selected by the Hash Function field.
+
+3.1.7. The Type Bit Maps Field
+
+ The Type Bit Maps field identifies the RRset types which exist at the
+ NSEC3 RR's original ownername.
+
+ The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
+ generation, and MUST be ignored during processing.
+
+ The RR type space is split into 256 window blocks, each representing
+ the low-order 8 bits of the 16-bit RR type space. Each block that
+ has at least one active RR type is encoded using a single octet
+ window number (from 0 to 255), a single octet bitmap length (from 1
+ to 32) indicating the number of octets used for the window block's
+ bitmap, and up to 32 octets (256 bits) of bitmap.
+
+ Blocks are present in the NSEC3 RR RDATA in increasing numerical
+ order.
+
+ "|" denotes concatenation
+
+ Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 9]
+
+Internet-Draft nsec3 February 2006
+
+
+ Each bitmap encodes the low-order 8 bits of RR types within the
+ window block, in network bit order. The first bit is bit 0. For
+ window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+ to RR type 2 (NS), and so forth. For window block 1, bit 1
+ corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
+ 1, it indicates that an RRset of that type is present for the NSEC3
+ RR's ownername. If a bit is set to 0, it indicates that no RRset of
+ that type is present for the NSEC3 RR's ownername.
+
+ Since bit 0 in window block 0 refers to the non-existing RR type 0,
+ it MUST be set to 0. After verification, the validator MUST ignore
+ the value of bit 0 in window block 0.
+
+ Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11]
+ (section 3.1) or within the range reserved for assignment only to
+ QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
+ zone data. If encountered, they must be ignored upon reading.
+
+ Blocks with no types present MUST NOT be included. Trailing zero
+ octets in the bitmap MUST be omitted. The length of each block's
+ bitmap is determined by the type code with the largest numerical
+ value, within that block, among the set of RR types present at the
+ NSEC3 RR's actual ownername. Trailing zero octets not specified MUST
+ be interpreted as zero octets.
+
+3.2. The NSEC3 RR Presentation Format
+
+ The presentation format of the RDATA portion is as follows:
+
+ The Opt-In Flag Field is represented as an unsigned decimal integer.
+ The value is either 0 or 1.
+
+ The Hash field is presented as a mnemonic of the hash or as an
+ unsigned decimal integer. The value has a maximum of 127.
+
+ The Iterations field is presented as an unsigned decimal integer.
+
+ The Salt Length field is not presented.
+
+ The Salt field is represented as a sequence of case-insensitive
+ hexadecimal digits. Whitespace is not allowed within the sequence.
+ The Salt Field is represented as "-" (without the quotes) when the
+ Salt Length field has value 0.
+
+ The Next Hashed Ownername field is represented as a sequence of case-
+ insensitive base32 digits, without whitespace.
+
+ The Type Bit Maps Field is represented as a sequence of RR type
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 10]
+
+Internet-Draft nsec3 February 2006
+
+
+ mnemonics. When the mnemonic is not known, the TYPE representation
+ as described in RFC 3597 [12] (section 5) MUST be used.
+
+
+4. Creating Additional NSEC3 RRs for Empty Non-Terminals
+
+ In order to prove the non-existence of a record that might be covered
+ by a wildcard, it is necessary to prove the existence of its closest
+ encloser. A closest encloser might be an empty non-terminal.
+
+ Additional NSEC3 RRs are generated for empty non-terminals. These
+ additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
+ existing RRs in the zone except that their type-maps only indicated
+ the existence of an NSEC3 RRset and an RRSIG RRset.
+
+ This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
+ not appear at names that did not exist before the zone was signed.
+ [Comment.1]
+
+
+5. Calculation of the Hash
+
+ Define H(x) to be the hash of x using the hash function selected by
+ the NSEC3 record and || to indicate concatenation. Then define:
+
+ IH(salt,x,0)=H(x || salt)
+
+ IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
+
+ Then the calculated hash of an ownername is
+ IH(salt,ownername,iterations-1), where the ownername is the canonical
+ form.
+
+ The canonical form of the ownername is the wire format of the
+ ownername where:
+ 1. The ownername is fully expanded (no DNS name compression) and
+ fully qualified;
+ 2. All uppercase US-ASCII letters are replaced by the corresponding
+ lowercase US-ASCII letters;
+ 3. If the ownername is a wildcard name, the ownername is in its
+ original unexpanded form, including the "*" label (no wildcard
+ substitution);
+ This form is as defined in section 6.2 of RFC 4034 ([4]).
+
+
+6. Including NSEC3 RRs in a Zone
+
+ Each ownername within the zone that owns authoritative RRsets MUST
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 11]
+
+Internet-Draft nsec3 February 2006
+
+
+ have a corresponding NSEC3 RR. Ownernames that correspond to
+ unsigned delegations MAY have a corresponding NSEC3 RR, however, if
+ there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
+ set to 1. Other non-authoritative RRs are not included in the set of
+ NSEC3 RRs.
+
+ Each empty non-terminal MUST have an NSEC3 record.
+
+ The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
+ value field in the zone SOA RR.
+
+ The type bitmap of every NSEC3 resource record in a signed zone MUST
+ indicate the presence of both the NSEC3 RR type itself and its
+ corresponding RRSIG RR type.
+
+ The following steps describe the proper construction of NSEC3
+ records. [Comment.2]
+ 1. For each unique original ownername in the zone, add an NSEC3
+ RRset. If Opt-In is being used, ownernames of unsigned
+ delegations may be excluded, but must be considered for empty-
+ non-terminals. The ownername of the NSEC3 RR is the hashed
+ equivalent of the original owner name, prepended to the zone
+ name. The Next Hashed Ownername field is left blank for the
+ moment. If Opt-In is being used, set the Opt-In bit to one.
+ 2. For each RRset at the original owner name, set the corresponding
+ bit in the type bit map.
+ 3. If the difference in number of labels between the apex and the
+ original ownername is greater then 1, additional NSEC3s need to
+ be added for every empty non-terminal between the apex and the
+ original ownername. This process may generate NSEC3 RRs with
+ duplicate hashed ownernames.
+ 4. Sort the set of NSEC3 RRs into hash order. Hash order is the
+ ascending numerical order of the non-encoded hash values.
+ 5. Combine NSEC3 RRs with identical hashed ownernames by replacing
+ with a single NSEC3 RR with the type map consisting of the union
+ of the types represented by the set of NSEC3 RRs.
+ 6. In each NSEC3 RR, insert the Next Hashed Ownername by using the
+ value of the next NSEC3 RR in hash order. The Next Hashed
+ Ownername of the last NSEC3 in the zone contains the value of the
+ hashed ownername of the first NSEC3 in the hash order.
+
+
+7. Responding to NSEC3 Queries
+
+ Since NSEC3 ownernames are not represented in the NSEC3 chain like
+ other zone ownernames, direct queries for NSEC3 ownernames present a
+ special case.
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 12]
+
+Internet-Draft nsec3 February 2006
+
+
+ The special case arises when the following are all true:
+ o The QNAME equals an existing NSEC3 ownername, and
+ o There are no other record types that exist at QNAME, and
+ o The QTYPE does not equal NSEC3.
+ These conditions describe a particular case: the answer should be a
+ NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to
+ include in the authority section.
+
+ However, the NSEC3 RRset with ownername equal to QNAME is able to
+ prove its own existence. Thus, when answering this query, the
+ authoritative server MUST include the NSEC3 RRset whose ownername
+ equals QNAME. This RRset proves that QNAME is an existing name with
+ types NSEC3 and RRSIG. The authoritative server MUST also include
+ the NSEC3 RRset that covers the hash of QNAME. This RRset proves
+ that no other types exist.
+
+ When validating a NOERROR/NODATA response, validators MUST check for
+ a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
+ (validated) NSEC3 RRset as proof that QNAME exists. The validator
+ MUST also check for an NSEC3 RRset that covers the hash of QNAME as
+ proof that QTYPE doesn't exist.
+
+ Other cases where the QNAME equals an existing NSEC3 ownername may be
+ answered normally.
+
+
+8. Special Considerations
+
+ The following paragraphs clarify specific behaviour explain special
+ considerations for implementations.
+
+8.1. Proving Nonexistence
+
+ If a wildcard resource record appears in a zone, its asterisk label
+ is treated as a literal symbol and is treated in the same way as any
+ other ownername for purposes of generating NSEC3 RRs. RFC 4035 [5]
+ describes the impact of wildcards on authenticated denial of
+ existence.
+
+ In order to prove there exist no RRs for a domain, as well as no
+ source of synthesis, an RR must be shown for the closest encloser,
+ and non-existence must be shown for all closer labels and for the
+ wildcard at the closest encloser.
+
+ This can be done as follows. If the QNAME in the query is
+ omega.alfa.beta.example, and the closest encloser is beta.example
+ (the nearest ancestor to omega.alfa.beta.example), then the server
+ should return an NSEC3 that demonstrates the nonexistence of
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 13]
+
+Internet-Draft nsec3 February 2006
+
+
+ alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
+ *.beta.example, and an NSEC3 that demonstrates the existence of
+ beta.example. This takes between one and three NSEC3 records, since
+ a single record can, by chance, prove more than one of these facts.
+
+ When a verifier checks this response, then the existence of
+ beta.example together with the non-existence of alfa.beta.example
+ proves that the closest encloser is indeed beta.example. The non-
+ existence of *.beta.example shows that there is no wildcard at the
+ closest encloser, and so no source of synthesis for
+ omega.alfa.beta.example. These two facts are sufficient to satisfy
+ the resolver that the QNAME cannot be resolved.
+
+ In practice, since the NSEC3 owner and next names are hashed, if the
+ server responds with an NSEC3 for beta.example, the resolver will
+ have to try successively longer names, starting with example, moving
+ to beta.example, alfa.beta.example, and so on, until one of them
+ hashes to a value that matches the interval (but not the ownername
+ nor next owner name) of one of the returned NSEC3s (this name will be
+ alfa.beta.example). Once it has done this, it knows the closest
+ encloser (i.e. beta.example), and can then easily check the other two
+ required proofs.
+
+ Note that it is not possible for one of the shorter names tried by
+ the resolver to be denied by one of the returned NSEC3s, since, by
+ definition, all these names exist and so cannot appear within the
+ range covered by an NSEC3. Note, however, that the first name that
+ the resolver tries MUST be the apex of the zone, since names above
+ the apex could be denied by one of the returned NSEC3s.
+
+8.2. Salting
+
+ Augmenting original ownernames with salt before hashing increases the
+ cost of a dictionary of pre-generated hash-values. For every bit of
+ salt, the cost of a precomputed dictionary doubles (because there
+ must be an entry for each word combined with each possible salt
+ value). The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
+ salt, multiplying the cost by 2^2040. This means that an attacker
+ must, in practice, recompute the dictionary each time the salt is
+ changed.
+
+ There MUST be at least one complete set of NSEC3s for the zone using
+ the same salt value.
+
+ The salt SHOULD be changed periodically to prevent precomputation
+ using a single salt. It is RECOMMENDED that the salt be changed for
+ every resigning.
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 14]
+
+Internet-Draft nsec3 February 2006
+
+
+ Note that this could cause a resolver to see records with different
+ salt values for the same zone. This is harmless, since each record
+ stands alone (that is, it denies the set of ownernames whose hashes,
+ using the salt in the NSEC3 record, fall between the two hashes in
+ the NSEC3 record) - it is only the server that needs a complete set
+ of NSEC3 records with the same salt in order to be able to answer
+ every possible query.
+
+ There is no prohibition with having NSEC3 with different salts within
+ the same zone. However, in order for authoritative servers to be
+ able to consistently find covering NSEC3 RRs, the authoritative
+ server MUST choose a single set of parameters (algorithm, salt, and
+ iterations) to use when selecting NSEC3s. In the absence of any
+ other metadata, the server does this by using the parameters from the
+ zone apex NSEC3, recognizable by the presence of the SOA bit in the
+ type map. If there is more than one NSEC3 record that meets this
+ description, then the server may arbitrarily choose one. Because of
+ this, if there is a zone apex NSEC3 RR within a zone, it MUST be part
+ of a complete NSEC3 set. Conversely, if there exists an incomplete
+ set of NSEC3 RRs using the same parameters within a zone, there MUST
+ NOT be an NSEC3 RR using those parameters with the SOA bit set.
+
+8.3. Iterations
+
+ Setting the number of iterations used allows the zone owner to choose
+ the cost of computing a hash, and so the cost of generating a
+ dictionary. Note that this is distinct from the effect of salt,
+ which prevents the use of a single precomputed dictionary for all
+ time.
+
+ Obviously the number of iterations also affects the zone owner's cost
+ of signing the zone as well as the verifiers cost of verifying the
+ zone. We therefore impose an upper limit on the number of
+ iterations. We base this on the number of iterations that
+ approximately doubles the cost of signing the zone.
+
+ A zone owner MUST NOT use a value higher than shown in the table
+ below for iterations. A resolver MAY treat a response with a higher
+ value as bogus.
+
+ +--------------+------------+
+ | RSA Key Size | Iterations |
+ +--------------+------------+
+ | 1024 | 3,000 |
+ | 2048 | 20,000 |
+ | 4096 | 150,000 |
+ +--------------+------------+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 15]
+
+Internet-Draft nsec3 February 2006
+
+
+ +--------------+------------+
+ | DSA Key Size | Iterations |
+ +--------------+------------+
+ | 1024 | 1,500 |
+ | 2048 | 5,000 |
+ +--------------+------------+
+
+ This table is based on 150,000 SHA-1's per second, 50 RSA signs per
+ second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1
+ sign per second for 4096 bit keys, 100 DSA signs per second for 1024
+ bit keys and 30 signs per second for 2048 bit keys.
+
+ Note that since RSA verifications are 10-100 times faster than
+ signatures (depending on key size), in the case of RSA the legal
+ values of iterations can substantially increase the cost of
+ verification.
+
+8.4. Hash Collision
+
+ Hash collisions occur when different messages have the same hash
+ value. The expected number of domain names needed to give a 1 in 2
+ chance of a single collision is about 2^(n/2) for a hash of length n
+ bits (i.e. 2^80 for SHA-1). Though this probability is extremely
+ low, the following paragraphs deal with avoiding collisions and
+ assessing possible damage in the event of an attack using hash
+ collisions.
+
+8.4.1. Avoiding Hash Collisions during generation
+
+ During generation of NSEC3 RRs, hash values are supposedly unique.
+ In the (academic) case of a collision occurring, an alternative salt
+ MUST be chosen and all hash values MUST be regenerated.
+
+8.4.2. Second Preimage Requirement Analysis
+
+ A cryptographic hash function has a second-preimage resistance
+ property. The second-preimage resistance property means that it is
+ computationally infeasible to find another message with the same hash
+ value as a given message, i.e. given preimage X, to find a second
+ preimage X' != X such that hash(X) = hash(X'). The work factor for
+ finding a second preimage is of the order of 2^160 for SHA-1. To
+ mount an attack using an existing NSEC3 RR, an adversary needs to
+ find a second preimage.
+
+ Assuming an adversary is capable of mounting such an extreme attack,
+ the actual damage is that a response message can be generated which
+ claims that a certain QNAME (i.e. the second pre-image) does exist,
+ while in reality QNAME does not exist (a false positive), which will
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 16]
+
+Internet-Draft nsec3 February 2006
+
+
+ either cause a security aware resolver to re-query for the non-
+ existent name, or to fail the initial query. Note that the adversary
+ can't mount this attack on an existing name but only on a name that
+ the adversary can't choose and does not yet exist.
+
+8.4.3. Possible Hash Value Truncation Method
+
+ The previous sections outlined the low probability and low impact of
+ a second-preimage attack. When impact and probability are low, while
+ space in a DNS message is costly, truncation is tempting. Truncation
+ might be considered to allow for shorter ownernames and rdata for
+ hashed labels. In general, if a cryptographic hash is truncated to n
+ bits, then the expected number of domains required to give a 1 in 2
+ probability of a single collision is approximately 2^(n/2) and the
+ work factor to produce a second preimage is 2^n.
+
+ An extreme hash value truncation would be truncating to the shortest
+ possible unique label value. This would be unwise, since the work
+ factor to produce second preimages would then approximate the size of
+ the zone (sketch of proof: if the zone has k entries, then the length
+ of the names when truncated down to uniqueness should be proportional
+ to log_2(k). Since the work factor to produce a second pre-image is
+ 2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where
+ C is some constant), i.e. C'k - a work factor of k).
+
+ Though the mentioned truncation can be maximized to a certain
+ extreme, the probability of collision increases exponentially for
+ every truncated bit. Given the low impact of hash value collisions
+ and limited space in DNS messages, the balance between truncation
+ profit and collision damage may be determined by local policy. Of
+ course, the size of the corresponding RRSIG RR is not reduced, so
+ truncation is of limited benefit.
+
+ Truncation could be signaled simply by reducing the length of the
+ first label in the ownername. Note that there would have to be a
+ corresponding reduction in the length of the Next Hashed Ownername
+ field.
+
+8.4.4. Server Response to a Run-time Collision
+
+ In the astronomically unlikely event that a server is unable to prove
+ nonexistence because the hash of the name that does not exist
+ collides with a name that does exist, the server is obviously broken,
+ and should, therefore, return a response with an RCODE of 2 (server
+ failure).
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 17]
+
+Internet-Draft nsec3 February 2006
+
+
+8.4.5. Parameters that Cover the Zone
+
+ Secondary servers (and perhaps other entities) need to reliably
+ determine which NSEC3 parameters (that is, hash, salt and iterations)
+ are present at every hashed ownername, in order to be able to choose
+ an appropriate set of NSEC3 records for negative responses. This is
+ indicated by the parameters at the apex: any set of parameters that
+ is used in an NSEC3 record whose original ownername is the apex of
+ the zone MUST be present throughout the zone.
+
+ A method to determine which NSEC3 in a complete chain corresponds to
+ the apex is to look for a NSEC3 RRset which has the SOA bit set in
+ the RDATA bit type maps field.
+
+
+9. Performance Considerations
+
+ Iterated hashes impose a performance penalty on both authoritative
+ servers and resolvers. Therefore, the number of iterations should be
+ carefully chosen. In particular it should be noted that a high value
+ for iterations gives an attacker a very good denial of service
+ attack, since the attacker need not bother to verify the results of
+ their queries, and hence has no performance penalty of his own.
+
+ On the other hand, nameservers with low query rates and limited
+ bandwidth are already subject to a bandwidth based denial of service
+ attack, since responses are typically an order of magnitude larger
+ than queries, and hence these servers may choose a high value of
+ iterations in order to increase the difficulty of offline attempts to
+ enumerate their namespace without significantly increasing their
+ vulnerability to denial of service attacks.
+
+
+10. IANA Considerations
+
+ IANA needs to allocate a RR type code for NSEC3 from the standard RR
+ type space (type XXX requested). IANA needs to open a new registry
+ for the NSEC3 Hash Functions. The range for this registry is 0-127.
+ Defined types are:
+
+ 0 is reserved.
+ 1 is SHA-1 ([13]).
+ 127 is experimental.
+
+
+11. Security Considerations
+
+ The NSEC3 records are still susceptible to dictionary attacks (i.e.
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 18]
+
+Internet-Draft nsec3 February 2006
+
+
+ the attacker retrieves all the NSEC3 records, then calculates the
+ hashes of all likely domain names, comparing against the hashes found
+ in the NSEC3 records, and thus enumerating the zone). These are
+ substantially more expensive than enumerating the original NSEC
+ records would have been, and in any case, such an attack could also
+ be used directly against the name server itself by performing queries
+ for all likely names, though this would obviously be more detectable.
+ The expense of this off-line attack can be chosen by setting the
+ number of iterations in the NSEC3 RR.
+
+ Domains are also susceptible to a precalculated dictionary attack -
+ that is, a list of hashes for all likely names is computed once, then
+ NSEC3 is scanned periodically and compared against the precomputed
+ hashes. This attack is prevented by changing the salt on a regular
+ basis.
+
+ Walking the NSEC3 RRs will reveal the total number of records in the
+ zone, and also what types they are. This could be mitigated by
+ adding dummy entries, but certainly an upper limit can always be
+ found.
+
+ Hash collisions may occur. If they do, it will be impossible to
+ prove the non-existence of the colliding domain - however, this is
+ fantastically unlikely, and, in any case, DNSSEC already relies on
+ SHA-1 to not collide.
+
+ Responses to queries where QNAME equals an NSEC3 ownername that has
+ no other types may be undetectably changed from a NOERROR/NODATA
+ response to a NAME ERROR response.
+
+ The Opt-In Flag (O) allows for unsigned names, in the form of
+ delegations to unsigned subzones, to exist within an otherwise signed
+ zone. All unsigned names are, by definition, insecure, and their
+ validity or existence cannot by cryptographically proven.
+
+ In general:
+ Records with unsigned names (whether existing or not) suffer from
+ the same vulnerabilities as records in an unsigned zone. These
+ vulnerabilities are described in more detail in [16] (note in
+ particular sections 2.3, "Name Games" and 2.6, "Authenticated
+ Denial").
+ Records with signed names have the same security whether or not
+ Opt-In is used.
+
+ Note that with or without Opt-In, an insecure delegation may be
+ undetectably altered by an attacker. Because of this, the primary
+ difference in security when using Opt-In is the loss of the ability
+ to prove the existence or nonexistence of an insecure delegation
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 19]
+
+Internet-Draft nsec3 February 2006
+
+
+ within the span of an Opt-In NSEC3 record.
+
+ In particular, this means that a malicious entity may be able to
+ insert or delete records with unsigned names. These records are
+ normally NS records, but this also includes signed wildcard
+ expansions (while the wildcard record itself is signed, its expanded
+ name is an unsigned name).
+
+ For example, if a resolver received the following response from the
+ example zone above:
+
+ Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
+
+ RCODE=NOERROR
+
+ Answer Section:
+
+ Authority Section:
+ DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
+ EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
+ RRSIG DNSKEY
+ abcd... RRSIG NSEC3 ...
+
+ Additional Section:
+
+ The resolver would have no choice but to accept that the referral to
+ NS.FORGED. is valid. If a wildcard existed that would have been
+ expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
+ have undetectably removed it and replaced it with the forged
+ delegation.
+
+ Note that being able to add a delegation is functionally equivalent
+ to being able to add any record type: an attacker merely has to forge
+ a delegation to nameserver under his/her control and place whatever
+ records needed at the subzone apex.
+
+ While in particular cases, this issue may not present a significant
+ security problem, in general it should not be lightly dismissed.
+ Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
+ In particular, zone signing tools SHOULD NOT default to using Opt-In,
+ and MAY choose to not support Opt-In at all.
+
+
+12. References
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 20]
+
+Internet-Draft nsec3 February 2006
+
+
+12.1. Normative References
+
+ [1] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [2] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
+ [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+ April 1997.
+
+ [7] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+ RFC 2181, July 1997.
+
+ [8] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+ RFC 2308, March 1998.
+
+ [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [10] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+ RFC 3658, December 2003.
+
+ [11] Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain
+ Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
+ September 2000.
+
+ [12] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+ Types", RFC 3597, September 2003.
+
+ [13] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
+ RFC 3174, September 2001.
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 21]
+
+Internet-Draft nsec3 February 2006
+
+
+12.2. Informative References
+
+ [14] Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)",
+ draft-vixie-dnssec-ter-01 (work in progress), June 2004.
+
+ [15] Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data
+ Encodings.", draft-josefsson-rfc3548bis-00 (work in progress),
+ October 2005.
+
+ [16] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
+ System (DNS)", RFC 3833, August 2004.
+
+Editorial Comments
+
+ [Comment.1] Although, strictly speaking, the names *did* exist.
+
+ [Comment.2] Note that this method makes it impossible to detect
+ (extremely unlikely) hash collisions.
+
+
+Appendix A. Example Zone
+
+ This is a zone showing its NSEC3 records. They can also be used as
+ test vectors for the hash algorithm.
+
+ The data in the example zone is currently broken, as it uses a
+ different base32 alphabet. This shall be fixed in the next release.
+
+
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600 )
+ 3600 RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ 3600 NS ns1.example.
+ 3600 NS ns2.example.
+ 3600 RRSIG NS 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+ m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+ 1SH5r/wfjuCg+g== )
+ 3600 MX 1 xx.example.
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 22]
+
+Internet-Draft nsec3 February 2006
+
+
+ 3600 RRSIG MX 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
+ NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
+ S/o/g5C8VM6ftQ== )
+ 3600 DNSKEY 257 3 5 (
+ AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
+ cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
+ zsYKWJ7BvR2894hX
+ ) ; Key ID = 21960
+ 3600 DNSKEY 256 3 5 (
+ AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
+ 5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
+ ExXT48OGGdbfIme5
+ ) ; Key ID = 62699
+ 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
+ xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
+ mTkunTYzqWJrmQ== )
+ 3600 RRSIG DNSKEY 5 1 3600 20050712112304 (
+ 20050612112304 21960 example.
+ SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
+ ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
+ 3w7ZY2UWyYIvpw== )
+ 5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ 7nomf47k3vlidh4vxahhpp47l3tgv7a2
+ NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
+ Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
+ sb7KfbaUo/vzAg== )
+ 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
+ MX NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
+ ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
+ MEFQmc/gEuxojA== )
+ a.example. 3600 IN NS ns1.a.example.
+ 3600 IN NS ns2.a.example.
+ 3600 DS 58470 5 1 3079F1593EBAD6DC121E202A8B
+ 766A6A4837206C )
+ 3600 RRSIG DS 5 2 3600 20050712112304 (
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 23]
+
+Internet-Draft nsec3 February 2006
+
+
+ 20050612112304 62699 example.
+ QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
+ cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
+ 0kx7rGKTc3RQDA== )
+ ns1.a.example. 3600 IN A 192.0.2.5
+ ns2.a.example. 3600 IN A 192.0.2.6
+ ai.example. 3600 IN A 192.0.2.9
+ 3600 RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
+ 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
+ ZXW5S+1VjMZYzQ== )
+ 3600 HINFO "KLH-10" "ITS"
+ 3600 RRSIG HINFO 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
+ tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
+ VGNmbgPnqDVPiA== )
+ 3600 AAAA 2001:db8:0:0:0:0:f00:baa9
+ 3600 RRSIG AAAA 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
+ ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
+ l5/UqLCJJ9BDMg== )
+ b.example. 3600 IN NS ns1.b.example.
+ 3600 IN NS ns2.b.example.
+ ns1.b.example. 3600 IN A 192.0.2.7
+ ns2.b.example. 3600 IN A 192.0.2.8
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ gmnfcccja7wkax3iv26bs75myptje3qk
+ MX DNSKEY NS SOA NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
+ C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
+ MOiKMSHozVebqw== )
+ gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
+ DS NS NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
+ ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
+ OwQBGbOegrW/Zw== )
+ jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 24]
+
+Internet-Draft nsec3 February 2006
+
+
+ kcll7fqfnisuhfekckeeqnmbbd4maanu
+ NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
+ IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
+ 94Zbq3k8lgdpZA== )
+ kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3 1 1 1 (
+ deadbeaf
+ n42hbhnjj333xdxeybycax5ufvntux5d
+ MX NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
+ IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
+ TOLtc5jPrkL4zQ== )
+ n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ nimwfwcnbeoodmsc6npv3vuaagaevxxu
+ A NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
+ 91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
+ xFPFGRIW3wKnrA== )
+ nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ vhgwr2qgykdkf4m6iv6vkagbxozphazr
+ HINFO A AAAA NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
+ z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
+ jL33Wm1p07TBdw== )
+ ns1.example. 3600 A 192.0.2.1
+ 3600 RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
+ BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
+ nWWLepz1PjjShQ== )
+ ns2.example. 3600 A 192.0.2.2
+ 3600 RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
+ P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
+ AkeTJu3J3auUiA== )
+ vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 25]
+
+Internet-Draft nsec3 February 2006
+
+
+ wbyijvpnyj33pcpi3i44ecnibnaj7eiw
+ HINFO A AAAA NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
+ kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
+ 5SNSHIyfpfsi6A== )
+ *.w.example. 3600 MX 1 ai.example.
+ 3600 RRSIG MX 5 3 3600 20050712112304 (
+ 20050612112304 62699 example.
+ sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
+ xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
+ gQlgxEwhvQDEaQ== )
+ x.w.example. 3600 MX 1 xx.example.
+ 3600 RRSIG MX 5 3 3600 20050712112304 (
+ 20050612112304 62699 example.
+ s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
+ lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
+ U9VazOa1KEIq1w== )
+ x.y.w.example. 3600 MX 1 xx.example.
+ 3600 RRSIG MX 5 4 3600 20050712112304 (
+ 20050612112304 62699 example.
+ aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
+ uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
+ 9VrQvJjwbllAfA== )
+ wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
+ A NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
+ ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
+ oorBv4xkb0flXw== )
+ xx.example. 3600 A 192.0.2.10
+ 3600 RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
+ tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
+ cxwCXWj82GVGdw== )
+ 3600 HINFO "KLH-10" "TOPS-20"
+ 3600 RRSIG HINFO 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
+ OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
+ KMf4DgNBDj+dIQ== )
+ 3600 AAAA 2001:db8:0:0:0:0:f00:baaa
+ 3600 RRSIG AAAA 5 2 3600 20050712112304 (
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 26]
+
+Internet-Draft nsec3 February 2006
+
+
+ 20050612112304 62699 example.
+ rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
+ w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
+ rzKKwb8J04/ILw== )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3 0 1 1 (
+ deadbeaf
+ 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+ MX NSEC3 RRSIG )
+ 3600 RRSIG NSEC3 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+ 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+ OcFlrPGPMm48/A== )
+
+
+Appendix B. Example Responses
+
+ The examples in this section show response messages using the signed
+ zone example in Appendix A.
+
+B.1. answer
+
+ A successful query to an authoritative server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 27]
+
+Internet-Draft nsec3 February 2006
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ x.w.example. IN MX
+
+ ;; Answer
+ x.w.example. 3600 IN MX 1 xx.example.
+ x.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
+ 20050612112304 62699 example.
+ s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
+ lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
+ U9VazOa1KEIq1w== )
+
+ ;; Authority
+ example. 3600 IN NS ns1.example.
+ example. 3600 IN NS ns2.example.
+ example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+ m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+ 1SH5r/wfjuCg+g== )
+
+ ;; Additional
+ xx.example. 3600 IN A 192.0.2.10
+ xx.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
+ tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
+ cxwCXWj82GVGdw== )
+ xx.example. 3600 IN AAAA 2001:db8::f00:baaa
+ xx.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
+ w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
+ rzKKwb8J04/ILw== )
+ ns1.example. 3600 IN A 192.0.2.1
+ ns1.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
+ BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
+ nWWLepz1PjjShQ== )
+ ns2.example. 3600 IN A 192.0.2.2
+ ns2.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
+ P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
+ AkeTJu3J3auUiA== )
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 28]
+
+Internet-Draft nsec3 February 2006
+
+
+ The query returned an MX RRset for "x.w.example". The corresponding
+ RRSIG RR indicates that the MX RRset was signed by an "example"
+ DNSKEY with algorithm 5 and key tag 62699. The resolver needs the
+ corresponding DNSKEY RR in order to authenticate this answer. The
+ discussion below describes how a resolver might obtain this DNSKEY
+ RR.
+
+ The RRSIG RR indicates the original TTL of the MX RRset was 3600,
+ and, for the purpose of authentication, the current TTL is replaced
+ by 3600. The RRSIG RR's labels field value of 3 indicates that the
+ answer was not the result of wildcard expansion. The "x.w.example"
+ MX RRset is placed in canonical form, and, assuming the current time
+ falls between the signature inception and expiration dates, the
+ signature is authenticated.
+
+B.1.1. Authenticating the Example DNSKEY RRset
+
+ This example shows the logical authentication process that starts
+ from a configured root DNSKEY RRset (or DS RRset) and moves down the
+ tree to authenticate the desired "example" DNSKEY RRset. Note that
+ the logical order is presented for clarity. An implementation may
+ choose to construct the authentication as referrals are received or
+ to construct the authentication chain only after all RRsets have been
+ obtained, or in any other combination it sees fit. The example here
+ demonstrates only the logical process and does not dictate any
+ implementation rules.
+
+ We assume the resolver starts with a configured DNSKEY RRset for the
+ root zone (or a configured DS RRset for the root zone). The resolver
+ checks whether this configured DNSKEY RRset is present in the root
+ DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
+ RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
+ root DNSKEY RRset, and whether the signature lifetime is valid. If
+ all these conditions are met, all keys in the DNSKEY RRset are
+ considered authenticated. The resolver then uses one (or more) of
+ the root DNSKEY RRs to authenticate the "example" DS RRset. Note
+ that the resolver may have to query the root zone to obtain the root
+ DNSKEY RRset or "example" DS RRset.
+
+ Once the DS RRset has been authenticated using the root DNSKEY, the
+ resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+ RR that matches one of the authenticated "example" DS RRs. If such a
+ matching "example" DNSKEY is found, the resolver checks whether this
+ DNSKEY RR has signed the "example" DNSKEY RRset and the signature
+ lifetime is valid. If these conditions are met, all keys in the
+ "example" DNSKEY RRset are considered authenticated.
+
+ Finally, the resolver checks that some DNSKEY RR in the "example"
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 29]
+
+Internet-Draft nsec3 February 2006
+
+
+ DNSKEY RRset uses algorithm 5 and has a key tag of 62699. This
+ DNSKEY is used to authenticate the RRSIG included in the response.
+ If multiple "example" DNSKEY RRs match this algorithm and key tag,
+ then each DNSKEY RR is tried, and the answer is authenticated if any
+ of the matching DNSKEY RRs validate the signature as described above.
+
+B.2. Name Error
+
+ An authoritative name error. The NSEC3 RRs prove that the name does
+ not exist and that no covering wildcard exists.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 30]
+
+Internet-Draft nsec3 February 2006
+
+
+ ;; Header: QR AA DO RCODE=3
+ ;;
+ ;; Question
+ a.c.x.w.example. IN A
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
+ MX NSEC3 RRSIG )
+ 7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
+ ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
+ MEFQmc/gEuxojA== )
+ nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ vhgwr2qgykdkf4m6iv6vkagbxozphazr
+ HINFO A AAAA NSEC3 RRSIG )
+ nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
+ z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
+ jL33Wm1p07TBdw== )
+ ;; Additional
+ ;; (empty)
+
+ The query returned two NSEC3 RRs that prove that the requested data
+ does not exist and no wildcard applies. The negative reply is
+ authenticated by verifying both NSEC3 RRs. The NSEC3 RRs are
+ authenticated in a manner identical to that of the MX RRset discussed
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 31]
+
+Internet-Draft nsec3 February 2006
+
+
+ above. At least one of the owner names of the NSEC3 RRs will match
+ the closest encloser. At least one of the NSEC3 RRs prove that there
+ exists no longer name. At least one of the NSEC3 RRs prove that
+ there exists no wildcard RRsets that should have been expanded. The
+ closest encloser can be found by hashing the apex ownername (The SOA
+ RR's ownername, or the ownername of the DNSKEY RRset referred by an
+ RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
+ if that fails, continue by adding labels. In other words, the
+ resolver first hashes example, checks for a matching NSEC3 ownername,
+ then hashes w.example, checks, and finally hashes w.x.example and
+ checks.
+
+ In the above example, the name 'x.w.example' hashes to
+ '7nomf47k3vlidh4vxahhpp47l3tgv7a2'. This indicates that this might
+ be the closest encloser. To prove that 'c.x.w.example' and
+ '*.x.w.example' do not exists, these names are hashed to respectively
+ 'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
+ 'cvljzyf6nsckjowghch4tt3nohocpdka'. The two NSEC3 records prove that
+ these hashed ownernames do not exists, since the names are within the
+ given intervals.
+
+B.3. No Data Error
+
+ A "no data" response. The NSEC3 RR proves that the name exists and
+ that the requested RR type does not.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 32]
+
+Internet-Draft nsec3 February 2006
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ ns1.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
+ A NSEC3 RRSIG )
+ wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
+ ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
+ oorBv4xkb0flXw== )
+ ;; Additional
+ ;; (empty)
+
+ The query returned an NSEC3 RR that proves that the requested name
+ exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
+ but the requested RR type does not exist (type MX is absent in the
+ type code list of the NSEC RR). The negative reply is authenticated
+ by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
+ identical to that of the MX RRset discussed above.
+
+B.3.1. No Data Error, Empty Non-Terminal
+
+ A "no data" response because of an empty non-terminal. The NSEC3 RR
+ proves that the name exists and that the requested RR type does not.
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 33]
+
+Internet-Draft nsec3 February 2006
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ y.w.example. IN A
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ kcll7fqfnisuhfekckeeqnmbbd4maanu
+ NSEC3 RRSIG )
+ jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
+ IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
+ 94Zbq3k8lgdpZA== )
+
+ The query returned an NSEC3 RR that proves that the requested name
+ exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
+ but the requested RR type does not exist (Type A is absent in the
+ type-bit-maps of the NSEC3 RR). The negative reply is authenticated
+ by verifying the NSEC3 RR. The NSEC3 RR is authenticated in a manner
+ identical to that of the MX RRset discussed above. Note that, unlike
+ generic empty non terminal proof using NSECs, this is identical to
+ proving a No Data Error. This example is solely mentioned to be
+ complete.
+
+B.4. Referral to Signed Zone
+
+ Referral to a signed zone. The DS RR contains the data which the
+ resolver will need to validate the corresponding DNSKEY RR in the
+ child zone's apex.
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 34]
+
+Internet-Draft nsec3 February 2006
+
+
+ ;; Header: QR DO RCODE=0
+ ;;
+
+ ;; Question
+ mc.a.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ a.example. 3600 IN NS ns1.a.example.
+ a.example. 3600 IN NS ns2.a.example.
+ a.example. 3600 IN DS 58470 5 1 (
+ 3079F1593EBAD6DC121E202A8B766A6A4837
+ 206C )
+ a.example. 3600 IN RRSIG DS 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
+ cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
+ 0kx7rGKTc3RQDA== )
+
+ ;; Additional
+ ns1.a.example. 3600 IN A 192.0.2.5
+ ns2.a.example. 3600 IN A 192.0.2.6
+
+ The query returned a referral to the signed "a.example." zone. The
+ DS RR is authenticated in a manner identical to that of the MX RRset
+ discussed above. This DS RR is used to authenticate the "a.example"
+ DNSKEY RRset.
+
+ Once the "a.example" DS RRset has been authenticated using the
+ "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+ for some "a.example" DNSKEY RR that matches the DS RR. If such a
+ matching "a.example" DNSKEY is found, the resolver checks whether
+ this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
+ the signature lifetime is valid. If all these conditions are met,
+ all keys in the "a.example" DNSKEY RRset are considered
+ authenticated.
+
+B.5. Referral to Unsigned Zone using the Opt-In Flag
+
+ The NSEC3 RR proves that nothing for this delegation was signed in
+ the parent zone. There is no proof that the delegation exists
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 35]
+
+Internet-Draft nsec3 February 2006
+
+
+ ;; Header: QR DO RCODE=0
+ ;;
+ ;; Question
+ mc.b.example. IN MX
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ b.example. 3600 IN NS ns1.b.example.
+ b.example. 3600 IN NS ns2.b.example.
+ kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3 1 1 1 (
+ deadbeaf
+ n42hbhnjj333xdxeybycax5ufvntux5d
+ MX NSEC3 RRSIG )
+ kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
+ IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
+ TOLtc5jPrkL4zQ== )
+
+ ;; Additional
+ ns1.b.example. 3600 IN A 192.0.2.7
+ ns2.b.example. 3600 IN A 192.0.2.8
+
+ The query returned a referral to the unsigned "b.example." zone. The
+ NSEC3 proves that no authentication leads from "example" to
+ "b.example", since the hash of "b.example"
+ ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
+ the NSEC3 opt-in bit is set. The NSEC3 RR is authenticated in a
+ manner identical to that of the MX RRset discussed above.
+
+B.6. Wildcard Expansion
+
+ A successful query that was answered via wildcard expansion. The
+ label count in the answer's RRSIG RR indicates that a wildcard RRset
+ was expanded to produce this response, and the NSEC3 RR proves that
+ no closer match exists in the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 36]
+
+Internet-Draft nsec3 February 2006
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ a.z.w.example. IN MX
+
+ ;; Answer
+ a.z.w.example. 3600 IN MX 1 ai.example.
+ a.z.w.example. 3600 IN RRSIG MX 5 3 3600 20050712112304 (
+ 20050612112304 62699 example.
+ sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
+ xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
+ gQlgxEwhvQDEaQ== )
+ ;; Authority
+ example. 3600 NS ns1.example.
+ example. 3600 NS ns2.example.
+ example. 3600 IN RRSIG NS 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
+ m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
+ 1SH5r/wfjuCg+g== )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+ MX NSEC3 RRSIG )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+ 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+ OcFlrPGPMm48/A== )
+ ;; Additional
+ ai.example. 3600 IN A 192.0.2.9
+ ai.example. 3600 IN RRSIG A 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
+ 6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
+ ZXW5S+1VjMZYzQ== )
+ ai.example. 3600 AAAA 2001:db8::f00:baa9
+ ai.example. 3600 IN RRSIG AAAA 5 2 3600 20050712112304 (
+ 20050612112304 62699 example.
+ PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
+ ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
+ l5/UqLCJJ9BDMg== )
+
+ The query returned an answer that was produced as a result of
+ wildcard expansion. The answer section contains a wildcard RRset
+ expanded as it would be in a traditional DNS response, and the
+ corresponding RRSIG indicates that the expanded wildcard MX RRset was
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 37]
+
+Internet-Draft nsec3 February 2006
+
+
+ signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
+ The RRSIG indicates that the original TTL of the MX RRset was 3600,
+ and, for the purpose of authentication, the current TTL is replaced
+ by 3600. The RRSIG labels field value of 2 indicates that the answer
+ is the result of wildcard expansion, as the "a.z.w.example" name
+ contains 4 labels. The name "a.z.w.example" is replaced by
+ "*.w.example", the MX RRset is placed in canonical form, and,
+ assuming that the current time falls between the signature inception
+ and expiration dates, the signature is authenticated.
+
+ The NSEC3 proves that no closer match (exact or closer wildcard)
+ could have been used to answer this query, and the NSEC3 RR must also
+ be authenticated before the answer is considered valid.
+
+B.7. Wildcard No Data Error
+
+ A "no data" response for a name covered by a wildcard. The NSEC3 RRs
+ prove that the matching wildcard name does not have any RRs of the
+ requested type and that no closer match exists in the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 38]
+
+Internet-Draft nsec3 February 2006
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ a.z.w.example. IN AAAA
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ 5pe7ctl7pfs2cilroy5dcofx4rcnlypd
+ MX NSEC3 RRSIG )
+ zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
+ 7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
+ OcFlrPGPMm48/A== )
+ ;; Additional
+ ;; (empty)
+
+ The query returned NSEC3 RRs that prove that the requested data does
+ not exist and no wildcard applies. The negative reply is
+ authenticated by verifying both NSEC3 RRs.
+
+B.8. DS Child Zone No Data Error
+
+ A "no data" response for a QTYPE=DS query that was mistakenly sent to
+ a name server for the child zone.
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 39]
+
+Internet-Draft nsec3 February 2006
+
+
+ ;; Header: QR AA DO RCODE=0
+ ;;
+ ;; Question
+ example. IN DS
+
+ ;; Answer
+ ;; (empty)
+
+ ;; Authority
+ example. 3600 IN SOA ns1.example. bugs.x.w.example. (
+ 1
+ 3600
+ 300
+ 3600000
+ 3600
+ )
+ example. 3600 IN RRSIG SOA 5 1 3600 20050712112304 (
+ 20050612112304 62699 example.
+ RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
+ mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
+ qYIt90txzE/4+g== )
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3 0 1 1 (
+ deadbeaf
+ gmnfcccja7wkax3iv26bs75myptje3qk
+ MX DNSKEY NS SOA NSEC3 RRSIG )
+ dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG NSEC3 (
+ 5 2 3600 20050712112304
+ 20050612112304 62699 example.
+ VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
+ C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
+ MOiKMSHozVebqw== )
+
+ ;; Additional
+ ;; (empty)
+
+ The query returned NSEC RRs that shows the requested was answered by
+ a child server ("example" server). The NSEC RR indicates the
+ presence of an SOA RR, showing that the answer is from the child .
+ Queries for the "example" DS RRset should be sent to the parent
+ servers ("root" servers).
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 40]
+
+Internet-Draft nsec3 February 2006
+
+
+Authors' Addresses
+
+ Ben Laurie
+ Nominet
+ 17 Perryn Road
+ London W3 7LR
+ England
+
+ Phone: +44 (20) 8735 0686
+ Email: ben@algroup.co.uk
+
+
+ Geoffrey Sisson
+ Nominet
+
+
+ Roy Arends
+ Nominet
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 41]
+
+Internet-Draft nsec3 February 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.
+
+
+
+
+Laurie, et al. Expires August 5, 2006 [Page 42]
+
diff --git a/doc/draft/draft-ietf-dnsext-nsid-01.txt b/doc/draft/draft-ietf-dnsext-nsid-01.txt
new file mode 100644
index 0000000..90d1a06
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-nsid-01.txt
@@ -0,0 +1,840 @@
+
+
+
+Network Working Group R. Austein
+Internet-Draft ISC
+Expires: July 15, 2006 January 11, 2006
+
+
+ DNS Name Server Identifier Option (NSID)
+ draft-ietf-dnsext-nsid-01
+
+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 July 15, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query. While existing ad-hoc
+ mechanism allow an operator to send follow-up queries when it is
+ necessary to debug such a configuration, the only completely reliable
+ way to obtain the identity of the name server which responded is to
+ have the name server include this information in the response itself.
+ This note defines a protocol extension to support this functionality.
+
+
+
+Austein Expires July 15, 2006 [Page 1]
+
+Internet-Draft DNS NSID January 2006
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1. Resolver Behavior . . . . . . . . . . . . . . . . . . . . 4
+ 2.2. Name Server Behavior . . . . . . . . . . . . . . . . . . . 4
+ 2.3. The NSID Option . . . . . . . . . . . . . . . . . . . . . 4
+ 2.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5
+ 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. The NSID Payload . . . . . . . . . . . . . . . . . . . . . 6
+ 3.2. NSID Is Not Transitive . . . . . . . . . . . . . . . . . . 8
+ 3.3. User Interface Issues . . . . . . . . . . . . . . . . . . 8
+ 3.4. Truncation . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ Intellectual Property and Copyright Statements . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Expires July 15, 2006 [Page 2]
+
+Internet-Draft DNS NSID January 2006
+
+
+1. Introduction
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query.
+
+ Existing ad-hoc mechanisms allow an operator to send follow-up
+ queries when it is necessary to debug such a configuration, but there
+ are situations in which this is not a totally satisfactory solution,
+ since anycast routing may have changed, or the server pool in
+ question may be behind some kind of extremely dynamic load balancing
+ hardware. Thus, while these ad-hoc mechanisms are certainly better
+ than nothing (and have the advantage of already being deployed), a
+ better solution seems desirable.
+
+ Given that a DNS query is an idempotent operation with no retained
+ state, it would appear that the only completely reliable way to
+ obtain the identity of the name server which responded to a
+ particular query is to have that name server include identifying
+ information in the response itself. This note defines a protocol
+ enhancement to achieve this.
+
+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 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Expires July 15, 2006 [Page 3]
+
+Internet-Draft DNS NSID January 2006
+
+
+2. Protocol
+
+ This note uses an EDNS [RFC2671] option to signal the resolver's
+ desire for information identifying the name server and to hold the
+ name server's response, if any.
+
+2.1. Resolver Behavior
+
+ A resolver signals its desire for information identifying a name
+ server by sending an empty NSID option (Section 2.3) in an EDNS OPT
+ pseudo-RR in the query message.
+
+ The resolver MUST NOT include any NSID payload data in the query
+ message.
+
+ The semantics of an NSID request are not transitive. That is: the
+ presence of an NSID option in a query is a request that the name
+ server which receives the query identify itself. If the name server
+ side of a recursive name server receives an NSID request, the client
+ is asking the recursive name server to identify itself; if the
+ resolver side of the recursive name server wishes to receive
+ identifying information, it is free to add NSID requests in its own
+ queries, but that is a separate matter.
+
+2.2. Name Server Behavior
+
+ A name server which understands the NSID option and chooses to honor
+ a particular NSID request responds by including identifying
+ information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
+ in the response message.
+
+ The name server MUST ignore any NSID payload data that might be
+ present in the query message.
+
+ The NSID option is not transitive. A name server MUST NOT send an
+ NSID option back to a resolver which did not request it. In
+ particular, while a recursive name server may choose to add an NSID
+ option when sending a query, this has no effect on the presence or
+ absence of the NSID option in the recursive name server's response to
+ the original client.
+
+ As stated in Section 2.1, this mechanism is not restricted to
+ authoritative name servers; the semantics are intended to be equally
+ applicable to recursive name servers.
+
+2.3. The NSID Option
+
+ The OPTION-CODE for the NSID option is [TBD].
+
+
+
+Austein Expires July 15, 2006 [Page 4]
+
+Internet-Draft DNS NSID January 2006
+
+
+ The OPTION-DATA for the NSID option is an opaque byte string the
+ semantics of which are deliberately left outside the protocol. See
+ Section 3.1 for discussion.
+
+2.4. Presentation Format
+
+ User interfaces MUST read and write the content of the NSID option as
+ a sequence of hexadecimal digits, two digits per payload octet.
+
+ The NSID payload is binary data. Any comparison between NSID
+ payloads MUST be a comparison of the raw binary data. Copy
+ operations MUST NOT assume that the raw NSID payload is null-
+ terminated. Any resemblance between raw NSID payload data and any
+ form of text is purely a convenience, and does not change the
+ underlying nature of the payload data.
+
+ See Section 3.3 for discussion.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Expires July 15, 2006 [Page 5]
+
+Internet-Draft DNS NSID January 2006
+
+
+3. Discussion
+
+ This section discusses certain aspects of the protocol and explains
+ considerations that led to the chosen design.
+
+3.1. The NSID Payload
+
+ The syntax and semantics of the content of the NSID option is
+ deliberately left outside the scope of this specification. This
+ section describe some of the kinds of data that server administrators
+ might choose to provide as the content of the NSID option, and
+ explains the reasoning behind choosing a simple opaque byte string.
+
+ There are several possibilities for the payload of the NSID option:
+
+ o It could be the "real" name of the specific name server within the
+ name server pool.
+
+ o It could be the "real" IP address (IPv4 or IPv6) of the name
+ server within the name server pool.
+
+ o It could be some sort of pseudo-random number generated in a
+ predictable fashion somehow using the server's IP address or name
+ as a seed value.
+
+ o It could be some sort of probabilisticly unique identifier
+ initially derived from some sort of random number generator then
+ preserved across reboots of the name server.
+
+ o It could be some sort of dynamicly generated identifier so that
+ only the name server operator could tell whether or not any two
+ queries had been answered by the same server.
+
+ o It could be a blob of signed data, with a corresponding key which
+ might (or might not) be available via DNS lookups.
+
+ o It could be a blob of encrypted data, the key for which could be
+ restricted to parties with a need to know (in the opinion of the
+ server operator).
+
+ o It could be an arbitrary string of octets chosen at the discretion
+ of the name server operator.
+
+ Each of these options has advantages and disadvantages:
+
+ o Using the "real" name is simple, but the name server may not have
+ a "real" name.
+
+
+
+
+Austein Expires July 15, 2006 [Page 6]
+
+Internet-Draft DNS NSID January 2006
+
+
+ o Using the "real" address is also simple, and the name server
+ almost certainly does have at least one non-anycast IP address for
+ maintenance operations, but the operator of the name server may
+ not be willing to divulge its non-anycast address.
+
+ o Given that one common reason for using anycast DNS techniques is
+ an attempt to harden a critical name server against denial of
+ service attacks, some name server operators are likely to want an
+ identifier other than the "real" name or "real" address of the
+ name server instance.
+
+ o Using a hash or pseudo-random number can provide a fixed length
+ value that the resolver can use to tell two name servers apart
+ without necessarily being able to tell where either one of them
+ "really" is, but makes debugging more difficult if one happens to
+ be in a friendly open environment. Furthermore, hashing might not
+ add much value, since a hash based on an IPv4 address still only
+ involves a 32-bit search space, and DNS names used for servers
+ that operators might have to debug at 4am tend not to be very
+ random.
+
+ o Probabilisticly unique identifiers have similar properties to
+ hashed identifiers, but (given a sufficiently good random number
+ generator) are immune to the search space issues. However, the
+ strength of this approach is also its weakness: there is no
+ algorithmic transformation by which even the server operator can
+ associate name server instances with identifiers while debugging,
+ which might be annoying. This approach also requires the name
+ server instance to preserve the probabilisticly unique identifier
+ across reboots, but this does not appear to be a serious
+ restriction, since authoritative nameservers almost always have
+ some form of nonvolatile storage in any case, and in the rare case
+ of a name server that does not have any way to store such an
+ identifier, nothing terrible will happen if the name server just
+ generates a new identifier every time it reboots.
+
+ o Using an arbitrary octet string gives name server operators yet
+ another thing to configure, or mis-configure, or forget to
+ configure. Having all the nodes in an anycast name server
+ constellation identify themselves as "My Name Server" would not be
+ particularly useful.
+
+ Given all of the issues listed above, there does not appear to be a
+ single solution that will meet all needs. Section 2.3 therefore
+ defines the NSID payload to be an opaque byte string and leaves the
+ choice up to the implementor and name server operator. The following
+ guidelines may be useful to implementors and server operators:
+
+
+
+
+Austein Expires July 15, 2006 [Page 7]
+
+Internet-Draft DNS NSID January 2006
+
+
+ o Operators for whom divulging the unicast address is an issue could
+ use the raw binary representation of a probabilisticly unique
+ random number. This should probably be the default implementation
+ behavior.
+
+ o Operators for whom divulging the unicast address is not an issue
+ could just use the raw binary representation of a unicast address
+ for simplicity. This should only be done via an explicit
+ configuration choice by the operator.
+
+ o Operators who really need or want the ability to set the NSID
+ payload to an arbitrary value could do so, but this should only be
+ done via an explicit configuration choice by the operator.
+
+ This approach appears to provide enough information for useful
+ debugging without unintentionally leaking the maintenance addresses
+ of anycast name servers to nogoodniks, while also allowing name
+ server operators who do not find such leakage threatening to provide
+ more information at their own discretion.
+
+3.2. NSID Is Not Transitive
+
+ As specified in Section 2.1 and Section 2.2, the NSID option is not
+ transitive. This is strictly a hop-by-hop mechanism.
+
+ Most of the discussion of name server identification to date has
+ focused on identifying authoritative name servers, since the best
+ known cases of anycast name servers are a subset of the name servers
+ for the root zone. However, given that anycast DNS techniques are
+ also applicable to recursive name servers, the mechanism may also be
+ useful with recursive name servers. The hop-by-hop semantics support
+ this.
+
+ While there might be some utility in having a transitive variant of
+ this mechanism (so that, for example, a stub resolver could ask a
+ recursive server to tell it which authoritative name server provided
+ a particular answer to the recursive name server), the semantics of
+ such a variant would be more complicated, and are left for future
+ work.
+
+3.3. User Interface Issues
+
+ Given the range of possible payload contents described in
+ Section 3.1, it is not possible to define a single presentation
+ format for the NSID payload that is efficient, convenient,
+ unambiguous, and aesthetically pleasing. In particular, while it is
+ tempting to use a presentation format that uses some form of textual
+ strings, attempting to support this would significantly complicate
+
+
+
+Austein Expires July 15, 2006 [Page 8]
+
+Internet-Draft DNS NSID January 2006
+
+
+ what's intended to be a very simple debugging mechanism.
+
+ In some cases the content of the NSID payload may be binary data
+ meaningful only to the name server operator, and may not be
+ meaningful to the user or application, but the user or application
+ must be able to capture the entire content anyway in order for it to
+ be useful. Thus, the presentation format must support arbitrary
+ binary data.
+
+ In cases where the name server operator derives the NSID payload from
+ textual data, a textual form such as US-ASCII or UTF-8 strings might
+ at first glance seem easier for a user to deal with. There are,
+ however, a number of complex issues involving internationalized text
+ which, if fully addressed here, would require a set of rules
+ significantly longer than the rest of this specification. See
+ [RFC2277] for an overview of some of these issues.
+
+ It is much more important for the NSID payload data to be passed
+ unambiguously from server administrator to user and back again than
+ it is for the payload data data to be pretty while in transit. In
+ particular, it's critical that it be straightforward for a user to
+ cut and paste an exact copy of the NSID payload output by a debugging
+ tool into other formats such as email messages or web forms without
+ distortion. Hexadecimal strings, while ugly, are also robust.
+
+3.4. Truncation
+
+ In some cases, adding the NSID option to a response message may
+ trigger message truncation. This specification does not change the
+ rules for DNS message truncation in any way, but implementors will
+ need to pay attention to this issue.
+
+ Including the NSID option in a response is always optional, so this
+ specification never requires name servers to truncate response
+ messages.
+
+ By definition, a resolver that requests NSID responses also supports
+ EDNS, so a resolver that requests NSID responses can also use the
+ "sender's UDP payload size" field of the OPT pseudo-RR to signal a
+ receive buffer size large enough to make truncation unlikely.
+
+
+
+
+
+
+
+
+
+
+
+Austein Expires July 15, 2006 [Page 9]
+
+Internet-Draft DNS NSID January 2006
+
+
+4. IANA Considerations
+
+ This mechanism requires allocation of one ENDS option code for the
+ NSID option (Section 2.3).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Expires July 15, 2006 [Page 10]
+
+Internet-Draft DNS NSID January 2006
+
+
+5. Security Considerations
+
+ This document describes a channel signaling mechanism, intended
+ primarily for debugging. Channel signaling mechanisms are outside
+ the scope of DNSSEC per se. Applications that require integrity
+ protection for the data being signaled will need to use a channel
+ security mechanism such as TSIG [RFC2845].
+
+ Section 3.1 discusses a number of different kinds of information that
+ a name server operator might choose to provide as the value of the
+ NSID option. Some of these kinds of information are security
+ sensitive in some environments. This specification deliberately
+ leaves the syntax and semantics of the NSID option content up to the
+ implementation and the name server operator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Expires July 15, 2006 [Page 11]
+
+Internet-Draft DNS NSID January 2006
+
+
+6. Acknowledgements
+
+ Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
+ Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
+ Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
+ Suzanne Woolf. Apologies to anyone inadvertently omitted from the
+ above list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Expires July 15, 2006 [Page 12]
+
+Internet-Draft DNS NSID January 2006
+
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+ RFC 2671, August 1999.
+
+ [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS
+ (TSIG)", RFC 2845, May 2000.
+
+7.2. Informative References
+
+ [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", RFC 2277, BCP 18, January 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Expires July 15, 2006 [Page 13]
+
+Internet-Draft DNS NSID January 2006
+
+
+Author's Address
+
+ Rob Austein
+ ISC
+ 950 Charter Street
+ Redwood City, CA 94063
+ USA
+
+ Email: sra@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein Expires July 15, 2006 [Page 14]
+
+Internet-Draft DNS NSID January 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.
+
+
+
+
+Austein Expires July 15, 2006 [Page 15]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
new file mode 100644
index 0000000..5b6d655
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
@@ -0,0 +1,464 @@
+
+INTERNET-DRAFT DSA Information in the DNS
+OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
+ Motorola Laboratories
+Expires: January 2006 July 2005
+
+
+ DSA Keying and Signature Information in the DNS
+ --- ------ --- --------- ----------- -- --- ---
+ <draft-ietf-dnsext-rfc2536bis-dsa-06.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 a "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.
+
+
+Copyright Notice
+
+ Copyright (C) The Internet Society 2005. All Rights Reserved.
+
+
+
+
+
+D. Eastlake 3rd [Page 1]
+
+
+INTERNET-DRAFT DSA Information in the DNS
+
+
+Table of Contents
+
+ Status of This Document....................................1
+ Abstract...................................................1
+ Copyright Notice...........................................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 and Disclaimer...................................5
+
+ Normative References.......................................7
+ Informative References.....................................7
+
+ Authors Address............................................8
+ Expiration and File Name...................................8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 2]
+
+
+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]
+
+
+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]
+
+
+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 and Disclaimer
+
+ Copyright (C) The Internet Society (2005). 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]
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 6]
+
+
+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]
+
+
+INTERNET-DRAFT DSA Information in the DNS
+
+
+Authors 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 January 2006.
+
+ Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 8]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
new file mode 100644
index 0000000..2ec9dbe
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
@@ -0,0 +1,840 @@
+
+
+
+Network Working Group S. Josefsson
+Internet-Draft August 30, 2005
+Expires: March 3, 2006
+
+
+ Storing Certificates in the Domain Name System (DNS)
+ draft-ietf-dnsext-rfc2538bis-04
+
+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 March 3, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ Cryptographic public keys are frequently published and their
+ authenticity demonstrated by certificates. A CERT resource record
+ (RR) is defined so that such certificates and related certificate
+ revocation lists can be stored in the Domain Name System (DNS).
+
+ This document obsoletes RFC 2538.
+
+
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 1]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3
+ 2.1. Certificate Type Values . . . . . . . . . . . . . . . . . 4
+ 2.2. Text Representation of CERT RRs . . . . . . . . . . . . . 5
+ 2.3. X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6
+ 3.1. Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
+ 3.2. Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8
+ 3.3. Content-based OpenPGP CERT RR Names . . . . . . . . . . . 9
+ 3.4. Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9
+ 3.5. Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9
+ 4. Performance Considerations . . . . . . . . . . . . . . . . . . 10
+ 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
+ 9. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
+ Appendix A. Copying conditions . . . . . . . . . . . . . . . . . 12
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ Intellectual Property and Copyright Statements . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 2]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+1. Introduction
+
+ Public keys are frequently published in the form of a certificate and
+ their authenticity is commonly demonstrated by certificates and
+ related certificate revocation lists (CRLs). A certificate is a
+ binding, through a cryptographic digital signature, of a public key,
+ a validity interval and/or conditions, and identity, authorization,
+ or other information. A certificate revocation list is a list of
+ certificates that are revoked, and incidental information, all signed
+ by the signer (issuer) of the revoked certificates. Examples are
+ X.509 certificates/CRLs in the X.500 directory system or OpenPGP
+ certificates/revocations used by OpenPGP software.
+
+ Section 2 below specifies a CERT resource record (RR) for the storage
+ of certificates in the Domain Name System [1] [2].
+
+ Section 3 discusses appropriate owner names for CERT RRs.
+
+ Sections 4, 5, and 6 below cover performance, IANA, and security
+ considerations, respectively.
+
+ 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 [3].
+
+
+2. The CERT Resource Record
+
+ The CERT resource record (RR) has the structure given below. Its RR
+ type code is 37.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | type | key tag |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | algorithm | /
+ +---------------+ certificate or CRL /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+ The type field is the certificate type as defined in section 2.1
+ below.
+
+ The key tag field is the 16 bit value computed for the key embedded
+ in the certificate, using the RRSIG Key Tag algorithm described in
+ Appendix B of [10]. This field is used as an efficiency measure to
+ pick which CERT RRs may be applicable to a particular key. The key
+
+
+
+Josefsson Expires March 3, 2006 [Page 3]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+ tag can be calculated for the key in question and then only CERT RRs
+ with the same key tag need be examined. However, the key must always
+ be transformed to the format it would have as the public key portion
+ of a DNSKEY RR before the key tag is computed. This is only possible
+ if the key is applicable to an algorithm (and limits such as key size
+ limits) defined for DNS security. If it is not, the algorithm field
+ MUST BE zero and the tag field is meaningless and SHOULD BE zero.
+
+ The algorithm field has the same meaning as the algorithm field in
+ DNSKEY and RRSIG RRs [10], except that a zero algorithm field
+ indicates the algorithm is unknown to a secure DNS, which may simply
+ be the result of the algorithm not having been standardized for
+ DNSSEC.
+
+2.1. Certificate Type Values
+
+ The following values are defined or reserved:
+
+ Value Mnemonic Certificate Type
+ ----- -------- ----------------
+ 0 reserved
+ 1 PKIX X.509 as per PKIX
+ 2 SPKI SPKI certificate
+ 3 PGP OpenPGP packet
+ 4 IPKIX The URL of an X.509 data object
+ 5 ISPKI The URL of an SPKI certificate
+ 6 IPGP The URL of an OpenPGP packet
+ 7-252 available for IANA assignment
+ 253 URI URI private
+ 254 OID OID private
+ 255-65534 available for IANA assignment
+ 65535 reserved
+
+ The PKIX type is reserved to indicate an X.509 certificate conforming
+ to the profile being defined by the IETF PKIX working group. The
+ certificate section will start with a one-byte unsigned OID length
+ and then an X.500 OID indicating the nature of the remainder of the
+ certificate section (see 2.3 below). (NOTE: X.509 certificates do
+ not include their X.500 directory type designating OID as a prefix.)
+
+ The SPKI type is reserved to indicate the SPKI certificate format
+ [13], for use when the SPKI documents are moved from experimental
+ status.
+
+ The PGP type indicates an OpenPGP packet as described in [6] and its
+ extensions and successors. Two uses are to transfer public key
+ material and revocation signatures. The data is binary, and MUST NOT
+ be encoded into an ASCII armor. An implementation SHOULD process
+
+
+
+Josefsson Expires March 3, 2006 [Page 4]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+ transferable public keys as described in section 10.1 of [6], but it
+ MAY handle additional OpenPGP packets.
+
+ The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
+ content that would have been in the "certificate, CRL or URL" field
+ of the corresponding (PKIX, SPKI or PGP) packet types. These types
+ are known as "indirect". These packet types MUST be used when the
+ content is too large to fit in the CERT RR, and MAY be used at the
+ implementer's discretion. They SHOULD NOT be used where the entire
+ UDP packet would have fit in 512 bytes.
+
+ The URI private type indicates a certificate format defined by an
+ absolute URI. The certificate portion of the CERT RR MUST begin with
+ a null terminated URI [5] and the data after the null is the private
+ format certificate itself. The URI SHOULD be such that a retrieval
+ from it will lead to documentation on the format of the certificate.
+ Recognition of private certificate types need not be based on URI
+ equality but can use various forms of pattern matching so that, for
+ example, subtype or version information can also be encoded into the
+ URI.
+
+ The OID private type indicates a private format certificate specified
+ by an ISO OID prefix. The certificate section will start with a one-
+ byte unsigned OID length and then a BER encoded OID indicating the
+ nature of the remainder of the certificate section. This can be an
+ X.509 certificate format or some other format. X.509 certificates
+ that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
+ type, not the OID private type. Recognition of private certificate
+ types need not be based on OID equality but can use various forms of
+ pattern matching such as OID prefix.
+
+2.2. Text Representation of CERT RRs
+
+ The RDATA portion of a CERT RR has the type field as an unsigned
+ decimal integer or as a mnemonic symbol as listed in section 2.1
+ above.
+
+ The key tag field is represented as an unsigned decimal integer.
+
+ The algorithm field is represented as an unsigned decimal integer or
+ a mnemonic symbol as listed in [10].
+
+ The certificate / CRL portion is represented in base 64 [14] and may
+ be divided up into any number of white space separated substrings,
+ down to single base 64 digits, which are concatenated to obtain the
+ full signature. These substrings can span lines using the standard
+ parenthesis.
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 5]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+ Note that the certificate / CRL portion may have internal sub-fields,
+ but these do not appear in the master file representation. For
+ example, with type 254, there will be an OID size, an OID, and then
+ the certificate / CRL proper. But only a single logical base 64
+ string will appear in the text representation.
+
+2.3. X.509 OIDs
+
+ OIDs have been defined in connection with the X.500 directory for
+ user certificates, certification authority certificates, revocations
+ of certification authority, and revocations of user certificates.
+ The following table lists the OIDs, their BER encoding, and their
+ length-prefixed hex format for use in CERT RRs:
+
+ id-at-userCertificate
+ = { joint-iso-ccitt(2) ds(5) at(4) 36 }
+ == 0x 03 55 04 24
+ id-at-cACertificate
+ = { joint-iso-ccitt(2) ds(5) at(4) 37 }
+ == 0x 03 55 04 25
+ id-at-authorityRevocationList
+ = { joint-iso-ccitt(2) ds(5) at(4) 38 }
+ == 0x 03 55 04 26
+ id-at-certificateRevocationList
+ = { joint-iso-ccitt(2) ds(5) at(4) 39 }
+ == 0x 03 55 04 27
+
+
+3. Appropriate Owner Names for CERT RRs
+
+ It is recommended that certificate CERT RRs be stored under a domain
+ name related to their subject, i.e., the name of the entity intended
+ to control the private key corresponding to the public key being
+ certified. It is recommended that certificate revocation list CERT
+ RRs be stored under a domain name related to their issuer.
+
+ Following some of the guidelines below may result in the use in DNS
+ names of characters that require DNS quoting which is to use a
+ backslash followed by the octal representation of the ASCII code for
+ the character (e.g., \000 for NULL).
+
+ The choice of name under which CERT RRs are stored is important to
+ clients that perform CERT queries. In some situations, the clients
+ may not know all information about the CERT RR object it wishes to
+ retrieve. For example, a client may not know the subject name of an
+ X.509 certificate, or the e-mail address of the owner of an OpenPGP
+ key. Further, the client might only know the hostname of a service
+ that uses X.509 certificates or the Key ID of an OpenPGP key.
+
+
+
+Josefsson Expires March 3, 2006 [Page 6]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+ Therefore, two owner name guidelines are defined: content-based owner
+ names and purpose-based owner names. A content-based owner name is
+ derived from the content of the CERT RR data; for example, the
+ Subject field in an X.509 certificate or the User ID field in OpenPGP
+ keys. A purpose-based owner name is a name that a client retrieving
+ CERT RRs MUST already know; for example, the host name of an X.509
+ protected service or the Key ID of an OpenPGP key. The content-based
+ and purpose-based owner name MAY be the same; for example, when a
+ client looks up a key based on the From: address of an incoming
+ e-mail.
+
+ Implementations SHOULD use the purpose-based owner name guidelines
+ described in this document, and MAY use CNAMEs of content-based owner
+ names (or other names), pointing to the purpose-based owner name.
+
+3.1. Content-based X.509 CERT RR Names
+
+ Some X.509 versions permit multiple names to be associated with
+ subjects and issuers under "Subject Alternate Name" and "Issuer
+ Alternate Name". For example, X.509v3 has such Alternate Names with
+ an ASN.1 specification as follows:
+
+ GeneralName ::= CHOICE {
+ otherName [0] INSTANCE OF OTHER-NAME,
+ rfc822Name [1] IA5String,
+ dNSName [2] IA5String,
+ x400Address [3] EXPLICIT OR-ADDRESS.&Type,
+ directoryName [4] EXPLICIT Name,
+ ediPartyName [5] EDIPartyName,
+ uniformResourceIdentifier [6] IA5String,
+ iPAddress [7] OCTET STRING,
+ registeredID [8] OBJECT IDENTIFIER
+ }
+
+ The recommended locations of CERT storage are as follows, in priority
+ order:
+ 1. If a domain name is included in the identification in the
+ certificate or CRL, that should be used.
+ 2. If a domain name is not included but an IP address is included,
+ then the translation of that IP address into the appropriate
+ inverse domain name should be used.
+ 3. If neither of the above is used, but a URI containing a domain
+ name is present, that domain name should be used.
+ 4. If none of the above is included but a character string name is
+ included, then it should be treated as described for OpenPGP
+ names below.
+
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 7]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+ 5. If none of the above apply, then the distinguished name (DN)
+ should be mapped into a domain name as specified in [4].
+
+ Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
+ DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
+ string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
+ uri <https://www.secure.john-doe.com:8080/>. The storage locations
+ recommended, in priority order, would be
+ 1. john-doe.com,
+ 2. www.secure.john-doe.com, and
+ 3. Doe.com.xy.
+
+ Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
+ L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
+ domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
+ (c) string "James Hacker <hacker@mail.widget.foo.example>". The
+ storage locations recommended, in priority order, would be
+ 1. widget.foo.example,
+ 2. 201.13.251.10.in-addr.arpa, and
+ 3. hacker.mail.widget.foo.example.
+
+3.2. Purpose-based X.509 CERT RR Names
+
+ Due to the difficulty for clients that do not already possess a
+ certificate to reconstruct the content-based owner name, purpose-
+ based owner names are recommended in this section. Recommendations
+ for purpose-based owner names vary per scenario. The following table
+ summarizes the purpose-based X.509 CERT RR owner name guidelines for
+ use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
+
+ Scenario Owner name
+ ------------------ ----------------------------------------------
+ S/MIME Certificate Standard translation of an RFC 2822 email
+ address. Example: An S/MIME certificate for
+ "postmaster@example.org" will use a standard
+ hostname translation of the owner name,
+ "postmaster.example.org".
+
+ TLS Certificate Hostname of the TLS server.
+
+ IPSEC Certificate Hostname of the IPSEC machine and/or, for IPv4
+ or IPv6 addresses, the fully qualified domain
+ name in the appropriate reverse domain.
+
+ An alternate approach for IPSEC is to store raw public keys [15].
+
+
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 8]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+3.3. Content-based OpenPGP CERT RR Names
+
+ OpenPGP signed keys (certificates) use a general character string
+ User ID [6]. However, it is recommended by OpenPGP that such names
+ include the RFC 2822 [8] email address of the party, as in "Leslie
+ Example <Leslie@host.example>". If such a format is used, the CERT
+ should be under the standard translation of the email address into a
+ domain name, which would be leslie.host.example in this case. If no
+ RFC 2822 name can be extracted from the string name, no specific
+ domain name is recommended.
+
+ If a user has more than one email address, the CNAME type can be used
+ to reduce the amount of data stored in the DNS. Example:
+
+ $ORIGIN example.org.
+ smith IN CERT PGP 0 0 <OpenPGP binary>
+ john.smith IN CNAME smith
+ js IN CNAME smith
+
+3.4. Purpose-based OpenPGP CERT RR Names
+
+ Applications that receive an OpenPGP packet containing encrypted or
+ signed data but do not know the email address of the sender will have
+ difficulties constructing the correct owner name and cannot use the
+ content-based owner name guidelines. However, these clients commonly
+ know the key fingerprint or the Key ID. The key ID is found in
+ OpenPGP packets, and the key fingerprint is commonly found in
+ auxilliary data that may be available. In this case, use of an owner
+ name identical to the key fingerprint and the key ID expressed in
+ hexadecimal [14] is recommended. Example:
+
+ $ORIGIN example.org.
+ 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
+ F835EDA21E94B565716F IN CERT PGP ...
+ B565716F IN CERT PGP ...
+
+ If the same key material is stored for several owner names, the use
+ of CNAME may be used to avoid data duplication. Note that CNAME is
+ not always applicable, because it maps one owner name to the other
+ for all purposes, which may be sub-optimal when two keys with the
+ same Key ID are stored.
+
+3.5. Owner names for IPKIX, ISPKI, and IPGP
+
+ These types are stored under the same owner names, both purpose- and
+ content-based, as the PKIX, SPKI and PGP types.
+
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 9]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+4. Performance Considerations
+
+ Current Domain Name System (DNS) implementations are optimized for
+ small transfers, typically not more than 512 bytes including
+ overhead. While larger transfers will perform correctly and work is
+ underway to make larger transfers more efficient, it is still
+ advisable at this time to make every reasonable effort to minimize
+ the size of certificates stored within the DNS. Steps that can be
+ taken may include using the fewest possible optional or extension
+ fields and using short field values for necessary variable length
+ fields.
+
+ The RDATA field in the DNS protocol may only hold data of size 65535
+ octets (64kb) or less. This means that each CERT RR MUST NOT contain
+ more than 64kb of payload, even if the corresponding certificate or
+ certificate revocation list is larger. This document addresses this
+ by defining "indirect" data types for each normal type.
+
+
+5. Contributors
+
+ The majority of this document is copied verbatim from RFC 2538, by
+ Donald Eastlake 3rd and Olafur Gudmundsson.
+
+
+6. Acknowledgements
+
+ Thanks to David Shaw and Michael Graff for their contributions to
+ earlier works that motivated, and served as inspiration for, this
+ document.
+
+ This document was improved by suggestions and comments from Olivier
+ Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
+ Sloderbeck, Samuel Weiler, and Florian Weimer. No doubt the list is
+ incomplete. We apologize to anyone we left out.
+
+
+7. Security Considerations
+
+ By definition, certificates contain their own authenticating
+ signature. Thus, it is reasonable to store certificates in non-
+ secure DNS zones or to retrieve certificates from DNS with DNS
+ security checking not implemented or deferred for efficiency. The
+ results MAY be trusted if the certificate chain is verified back to a
+ known trusted key and this conforms with the user's security policy.
+
+ Alternatively, if certificates are retrieved from a secure DNS zone
+ with DNS security checking enabled and are verified by DNS security,
+
+
+
+Josefsson Expires March 3, 2006 [Page 10]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+ the key within the retrieved certificate MAY be trusted without
+ verifying the certificate chain if this conforms with the user's
+ security policy.
+
+ If an organization chooses to issue certificates for it's employees,
+ placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
+ is in use, it is possible for someone to enumerate all employees of
+ the organization. This is usually not considered desirable, for the
+ same reason enterprise phone listings are not often publicly
+ published and are even mark confidential.
+
+ When the URI type is used, it should be understood that it introduces
+ an additional indirection that may allow for a new attack vector.
+ One method to secure that indirection is to include a hash of the
+ certificate in the URI itself.
+
+ CERT RRs are not used by DNSSEC [9], so there are no security
+ considerations related to CERT RRs and securing the DNS itself.
+
+ If DNSSEC is used, then the non-existence of a CERT RR and,
+ consequently, certificates or revocation lists can be securely
+ asserted. Without DNSSEC, this is not possible.
+
+
+8. IANA Considerations
+
+ Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
+ only be assigned by an IETF standards action [7]. This document
+ assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate
+ types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
+ based on RFC documentation of the certificate type. The availability
+ of private types under 0x00FD and 0x00FE should satisfy most
+ requirements for proprietary or private types.
+
+ The CERT RR reuses the DNS Security Algorithm Numbers registry. In
+ particular, the CERT RR requires that algorithm number 0 remain
+ reserved, as described in Section 2. The IANA is directed to
+ reference the CERT RR as a user of this registry and value 0, in
+ particular.
+
+
+9. Changes since RFC 2538
+
+ 1. Editorial changes to conform with new document requirements,
+ including splitting reference section into two parts and
+ updating the references to point at latest versions, and to add
+ some additional references.
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 11]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+ 2. Improve terminology. For example replace "PGP" with "OpenPGP",
+ to align with RFC 2440.
+ 3. In section 2.1, clarify that OpenPGP public key data are binary,
+ not the ASCII armored format, and reference 10.1 in RFC 2440 on
+ how to deal with OpenPGP keys, and acknowledge that
+ implementations may handle additional packet types.
+ 4. Clarify that integers in the representation format are decimal.
+ 5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
+ terminology. Improve reference for Key Tag Algorithm
+ calculations.
+ 6. Add examples that suggest use of CNAME to reduce bandwidth.
+ 7. In section 3, appended the last paragraphs that discuss
+ "content-based" vs "purpose-based" owner names. Add section 3.2
+ for purpose-based X.509 CERT owner names, and section 3.4 for
+ purpose-based OpenPGP CERT owner names.
+ 8. Added size considerations.
+ 9. The SPKI types has been reserved, until RFC 2692/2693 is moved
+ from the experimental status.
+ 10. Added indirect types IPKIX, ISPKI, and IPGP.
+
+
+Appendix A. Copying conditions
+
+ Regarding the portion of this document that was written by Simon
+ Josefsson ("the author", for the remainder of this section), the
+ author makes no guarantees and is not responsible for any damage
+ resulting from its use. The author grants irrevocable permission to
+ anyone to use, modify, and distribute it in any way that does not
+ diminish the rights of anyone else to use, modify, and distribute it,
+ provided that redistributed derivative works do not contain
+ misleading author or version information. Derivative works need not
+ be licensed under similar terms.
+
+
+10. References
+
+10.1. Normative References
+
+ [1] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [2] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
+
+
+
+Josefsson Expires March 3, 2006 [Page 12]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+ "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
+ January 1998.
+
+ [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+ [6] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
+ "OpenPGP Message Format", RFC 2440, November 1998.
+
+ [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+ [9] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [10] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+10.2. Informative References
+
+ [11] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
+
+ [12] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+ [13] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
+ and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
+ September 1999.
+
+ [14] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+ RFC 3548, July 2003.
+
+ [15] Richardson, M., "A Method for Storing IPsec Keying Material in
+ DNS", RFC 4025, March 2005.
+
+ [16] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+ (S/MIME) Version 3.1 Message Specification", RFC 3851,
+ July 2004.
+
+
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 13]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+Author's Address
+
+ Simon Josefsson
+
+ Email: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 14]
+
+Internet-Draft Storing Certificates in the DNS August 2005
+
+
+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 (2005). 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.
+
+
+
+
+Josefsson Expires March 3, 2006 [Page 15]
+
diff --git a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
new file mode 100644
index 0000000..5e6cb1d
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
@@ -0,0 +1,580 @@
+
+INTERNET-DRAFT Diffie-Hellman Information in the DNS
+OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
+ Motorola Laboratories
+Expires: January 2006 July 2005
+
+
+
+
+ Storage of Diffie-Hellman Keying Information in the DNS
+ ------- -- -------------- ------ ----------- -- --- ---
+ <draft-ietf-dnsext-rfc2539bis-dhk-06.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 a "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.
+
+
+
+Copyright
+
+ Copyright (C) The Internet Society 2005.
+
+
+
+D. Eastlake 3rd [Page 1]
+
+
+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
+ Copyright..................................................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 and Disclaimer...................................5
+
+ Normative References.......................................7
+ Informative Refences.......................................7
+
+ Author 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]
+
+
+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].
+
+
+
+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
+ key is the pair p and g, which must be the same for the parties, and
+ their individual X (or Y).
+
+ For further information about Diffie-Hellman and precautions to take
+
+
+D. Eastlake 3rd [Page 3]
+
+
+INTERNET-DRAFT Diffie-Hellman Information in the DNS
+
+
+ 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]
+
+
+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 and Disclaimer
+
+ Copyright (C) The Internet Society (2005). 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]
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 6]
+
+
+INTERNET-DRAFT Diffie-Hellman Information in the DNS
+
+
+Normative References
+
+ [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
+ 1999.
+
+ [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
+ in RFCs", T. Narten, H. Alvestrand, October 1998.
+
+ [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]
+
+
+INTERNET-DRAFT Diffie-Hellman Information in the DNS
+
+
+Author 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 January 2006.
+
+ Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 8]
+
+
+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]
+
+
+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]
+
diff --git a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
new file mode 100644
index 0000000..0af13c6
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
@@ -0,0 +1,755 @@
+
+
+Network Working Group B. Laurie
+Internet-Draft Nominet
+Expires: March 2, 2005 R. Loomis
+ SAIC
+ September 2004
+
+
+
+ Requirements related to DNSSEC Signed Proof of Non-Existence
+ draft-ietf-dnsext-signed-nonexistence-requirements-01
+
+
+Status of this Memo
+
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
+ RFC 3668.
+
+
+ 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 March 2, 2005.
+
+
+Copyright Notice
+
+
+ Copyright (C) The Internet Society (2004).
+
+
+Abstract
+
+
+ DNSSEC-bis uses the NSEC record to provide authenticated denial of
+ existence of RRsets. NSEC also has the side-effect of permitting
+ zone enumeration, even if zone transfers have been forbidden.
+ Because some see this as a problem, this document has been assembled
+ to detail the possible requirements for denial of existence A/K/A
+ signed proof of non-existence.
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 1]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+Table of Contents
+
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Non-purposes . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Zone Enumeration . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Zone Enumeration II . . . . . . . . . . . . . . . . . . . . 4
+ 5. Zone Enumeration III . . . . . . . . . . . . . . . . . . . . 4
+ 6. Exposure of Contents . . . . . . . . . . . . . . . . . . . . 4
+ 7. Zone Size . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 8. Single Method . . . . . . . . . . . . . . . . . . . . . . . 5
+ 9. Empty Non-terminals . . . . . . . . . . . . . . . . . . . . 5
+ 10. Prevention of Precomputed Dictionary Attacks . . . . . . . . 6
+ 11. DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . . 6
+ 12. Non-overlap of denial records with possible zone records . . 7
+ 13. Exposure of Private Keys . . . . . . . . . . . . . . . . . . 7
+ 14. Minimisation of Zone Signing Cost . . . . . . . . . . . . . 8
+ 15. Minimisation of Asymmetry . . . . . . . . . . . . . . . . . 8
+ 16. Minimisation of Client Complexity . . . . . . . . . . . . . 8
+ 17. Completeness . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 18. Purity of Namespace . . . . . . . . . . . . . . . . . . . . 8
+ 19. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . . 8
+ 20. Compatibility with NSEC . . . . . . . . . . . . . . . . . . 8
+ 21. Compatibility with NSEC II . . . . . . . . . . . . . . . . . 9
+ 22. Compatibility with NSEC III . . . . . . . . . . . . . . . . 9
+ 23. Coexistence with NSEC . . . . . . . . . . . . . . . . . . . 9
+ 24. Coexistence with NSEC II . . . . . . . . . . . . . . . . . . 9
+ 25. Protocol Design . . . . . . . . . . . . . . . . . . . . . . 9
+ 26. Process . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 27. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
+ 28. Requirements notation . . . . . . . . . . . . . . . . . . . 9
+ 29. Security Considerations . . . . . . . . . . . . . . . . . . 10
+ 30. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 30.1 Normative References . . . . . . . . . . . . . . . . . . . 10
+ 30.2 Informative References . . . . . . . . . . . . . . . . . . 10
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10
+ Intellectual Property and Copyright Statements . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 2]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+1. Introduction
+
+
+ NSEC records allow trivial enumeration of zones - a situation that
+ has existed for several years but which has recently been raised as a
+ significant concern for DNSSECbis deployment in several zones.
+ Alternate proposals have been made that make zone enumeration more
+ difficult, and some previous proposals to modify DNSSEC had related
+ requirements/desirements that are relevant to the discussion. In
+ addition the original designs for NSEC/NXT records were based on
+ working group discussions and the choices made were not always
+ documented with context and requirements-- so some of those choices
+ may need to be restated as requirements. Overall, the working group
+ needs to better understand the requirements for denial of existence
+ (and certain other requirements related to DNSSECbis deployment) in
+ order to evaluate the proposals that may replace NSEC.
+
+
+ In the remainder of this document, "NSEC++" is used as shorthand for
+ "a denial of existence proof that will replace NSEC". "NSECbis" has
+ also been used as shorthand for this, but we avoid that usage since
+ NSECbis will not be part of DNSSECbis and therefore there might be
+ some confusion.
+
+
+2. Non-purposes
+
+
+ This document does not currently document the reasons why zone
+ enumeration might be "bad" from a privacy, security, business, or
+ other perspective--except insofar as those reasons result in
+ requirements. Once the list of requirements is complete and vaguely
+ coherent, the trade-offs (reducing zone enumeration will have X cost,
+ while providing Y benefit) may be revisited. The editors of this
+ compendium received inputs on the potential reasons why zone
+ enumeration is bad (and there was significant discussion on the
+ DNSEXT WG mailing list) but that information fell outside the scope
+ of this document.
+
+
+ Note also that this document does not assume that NSEC *must* be
+ replaced with NSEC++, if the requirements can be met through other
+ methods (e.g., "white lies" with the current NSEC). As is stated
+ above, this document is focused on requirements collection and
+ (ideally) prioritization rather than on the actual implementation.
+
+
+3. Zone Enumeration
+
+
+ Authenticated denial should not permit trivial zone enumeration.
+
+
+ Additional discussion: NSEC (and NXT before it) provide a linked
+ list that could be "walked" to trivially enumerate all the signed
+ records in a zone. This requirement is primarily (though not
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 3]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+ exclusively) important for zones that either are delegation-only/
+ -mostly or do not have reverse lookup (PTR) records configured, since
+ enterprises that have PTR records for all A records have already
+ provided a similar capability to enumerate the contents of DNS zones.
+
+
+ Contributor: various
+
+
+4. Zone Enumeration II
+
+
+ Zone enumeration should be at least as difficult as it would be to
+ effect a dictionary attack using simple DNS queries to do the same in
+ an unsecured zone.
+
+
+ (Editor comment: it is not clear how to measure difficulty in this
+ case. Some examples could be monetary cost, bandwidth, processing
+ power or some combination of these. It has also been suggested that
+ the requirement is that the graph of difficulty of enumeration vs.
+ the fraction of the zone enumerated should be approximately the same
+ shape in the two cases)
+
+
+ Contributor: Nominet
+
+
+5. Zone Enumeration III
+
+
+ Enumeration of a zone with random contents should computationally
+ infeasible.
+
+
+ Editor comment: this is proposed as a way of evaluating the
+ effectiveness of a proposal rather than as a requirement anyone would
+ actually have in practice.
+
+
+ Contributor: Alex Bligh
+
+
+6. Exposure of Contents
+
+
+ NSEC++ should not expose any of the contents of the zone (apart from
+ the NSEC++ records themselves, of course).
+
+
+ Editor comment: this is a weaker requirement than prevention of
+ enumeration, but certainly any zone that satisfied this requirement
+ would also satisfy the trivial prevention of enumeration requirement.
+
+
+ Contributor: Ed Lewis
+
+
+7. Zone Size
+
+
+ Requirement: NSEC++ should make it possible to take precautions
+ against trivial zone size estimates. Since not all zone owners care
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 4]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+ about others estimation of the size of a zone, it is not always
+ necessary to prohibit trivial estimation of the size of the zone but
+ NSEC++ should allow such measures.
+
+
+ Additional Discussion: Even with proposals based on obfuscating names
+ with hashes it is trivial to give very good estimates of the number
+ of domains in a certain zone. Just send 10 random queries and look
+ at the range between the two hash values returned in each NSEC++. As
+ hash output can be assumed to follow a rectangular random
+ distribution, using the mean difference between the two values, you
+ can estimate the total number of records. It is probably sufficient
+ to look at even one NSEC++, since the two hash values should follow a
+ (I believe) Poisson distribution.
+
+
+ The concern is motivated by some wording remembered from NSEC, which
+ stated that NSEC MUST only be present for existing owner names in the
+ zone, and MUST NOT be present for non-existing owner names. If
+ similar wording were carried over to NSEC++, introducing bogus owner
+ names in the hash chain (an otherwise simple solution to guard
+ against trivial estimates of zone size) wouldn't be allowed.
+
+
+ One simple attempt at solving this is to describe in the
+ specifications how zone signer tools can add a number of random
+ "junk" records.
+
+
+ Editor's comment: it is interesting that obfuscating names might
+ actually make it easier to estimate zone size.
+
+
+ Contributor: Simon Josefsson.
+
+
+8. Single Method
+
+
+ Requirement: A single NSEC++ method must be able to carry both
+ old-style denial (i.e. plain labels) and whatever the new style
+ looks like. Having two separate denial methods could result in
+ cornercases where one method can deny the other and vice versa.
+
+
+ Additional discussion: This requirement can help -bis folks to a
+ smooth upgrade to -ter. First they'd change the method while the
+ content is the same, then they can change content of the method.
+
+
+ Contributor: Roy Arends.
+
+
+9. Empty Non-terminals
+
+
+ Requirement: Empty-non-terminals (ENT) should remain empty. In
+ other words, adding NSEC++ records to an existing DNS structure
+ should not cause the creation of NSEC++ records (or related records)
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 5]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+ at points that are otherwise ENT.
+
+
+ Additional discussion: Currently NSEC complies with ENT requirement:
+ b.example.com NSEC a.c.example.com implies the existence of an ENT
+ with ownername c.example.com. NSEC2 breaks that requirement, since
+ the ownername is entirely hashed causing the structure to disappear.
+ This is why EXIST was introduced. But EXIST causes ENT to be
+ non-empty-terminals. Next to the dissappearance of ENT, it causes
+ (some) overhead since an EXIST record needs a SIG, NSEC2 and
+ SIG(NSEC2). DNSNR honours this requirement by hashing individual
+ labels instead of ownernames. However this causes very long labels.
+ Truncation is a measure against very long ownernames, but that is
+ controversial. There is a fair discussion of the validity of
+ truncation in the DNSNR draft, but that hasn't got proper review yet.
+
+
+ Contributor: Roy Arends.
+
+
+ (Editor comment: it is not clear to us that an EXIST record needs an
+ NSEC2 record, since it is a special purpose record only used for
+ denial of existence)
+
+
+10. Prevention of Precomputed Dictionary Attacks
+
+
+ Requirement: NSEC++ needs to provide a method to reduce the
+ effectiveness of precomputed dictionary attacks.
+
+
+ Additional Discussion: Salt is a measure against dictionary attacks.
+ There are other possible measures (such as iterating hashes in
+ NSEC2). The salt needs to be communicated in every response, since
+ it is needed in every verification. Some have suggested to move the
+ salt to a special record instead of the denial record. I think this
+ is not wise. Response size has more priority over zone size. An
+ extra record causes a larger response than a larger existing record.
+
+
+ Contributor: Roy Arends.
+
+
+ (Editor comment: the current version of NSEC2 also has the salt in
+ every NSEC2 record)
+
+
+11. DNSSEC-Adoption and Zone-Growth Relationship
+
+
+ Background: Currently with NSEC, when a delegation centric zone
+ deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
+ when the DNSSEC-adoption rate of the subzones remains low--because
+ each delegation point creates at least one NSEC record and
+ corresponding signature in the parent even if the child is not
+ signed.
+
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 6]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+ Requirements: A delegation-only (or delegation-mostly) zone that is
+ signed but which has no signed child zones should initially need only
+ to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
+ minimal set of NSEC++ records to cover zone contents. Further,
+ during the transition of a delegation-only zone from 0% signed
+ children to 100% signed children, the growth in the delegation-only
+ zone should be roughly proportional to the percentage of signed child
+ zones.
+
+
+ Additional Discussion: This is why DNSNR has the Authoritative Only
+ bit. This is similar to opt-in for delegations only. This (bit) is
+ currently the only method to help delegation-centric zone cope with
+ zone-growth due to DNSSEC adoption. As an example, A delegation only
+ zone which deploys DNSSEC with the help of this bit, needs to add
+ SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex. No
+ more than that.
+
+
+ Contributor: Roy Arends.
+
+
+12. Non-overlap of denial records with possible zone records
+
+
+ Requirement: NSEC++ records should in some way be differentiated
+ from regular zone records, so that there is no possibility that a
+ record in the zone could be duplicated by a non-existence proof
+ (NSEC++) record.
+
+
+ Additional discussion: This requirement is derived from a discussion
+ on the DNSEXT mailing list related to copyrights and domain names.
+ As was outlined there, one solution is to put NSEC++ records in a
+ separate namespace, e.g.: $ORIGIN co.uk.
+ 873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
+ delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
+ ; for amazon.co.uk.
+
+
+ Contributor: various
+
+
+ (Editor comment: One of us still does not see why a conflict
+ matters. Even if there is an apparent conflict or overlap, the
+ "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
+ other name _never_ appears in NSEC2 records.)
+
+
+13. Exposure of Private Keys
+
+
+ Private keys associated with the public keys in the DNS should be
+ exposed as little as possible. It is highly undesirable for private
+ keys to be distributed to nameservers, or to otherwise be available
+ in the run-time environment of nameservers.
+
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 7]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+ Contributors: Nominet, Olaf Kolkman, Ed Lewis
+
+
+14. Minimisation of Zone Signing Cost
+
+
+ The additional cost of creating an NSEC++ signed zone should not
+ significantly exceed the cost of creating an ordinary signed zone.
+
+
+ Contributor: Nominet
+
+
+15. Minimisation of Asymmetry
+
+
+ Nameservers should have to do as little additional work as necessary.
+ More precisely, it is desirable for any increase in cost incurred by
+ the nameservers to be offset by a proportionate increase in cost to
+ DNS `clients', e.g. stub and/or `full-service' resolvers.
+
+
+ Contributor: Nominet
+
+
+16. Minimisation of Client Complexity
+
+
+ Caching, wildcards, CNAMEs, DNAMEs should continue to work without
+ adding too much complexity at the client side.
+
+
+ Contributor: Olaf Kolkman
+
+
+17. Completeness
+
+
+ A proof of nonexistence should be possible for all nonexistent data
+ in the zone.
+
+
+ Contributor: Olaf Kolkman
+
+
+18. Purity of Namespace
+
+
+ The name space should not be muddied with fake names or data sets.
+
+
+ Contributor: Ed Lewis
+
+
+19. Replay Attacks
+
+
+ NSEC++ should not allow a replay to be used to deny existence of an
+ RR that actually exists.
+
+
+ Contributor: Ed Lewis
+
+
+20. Compatibility with NSEC
+
+
+ NSEC++ should not introduce changes incompatible with NSEC.
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 8]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+ Contributor: Ed Lewis
+
+
+21. Compatibility with NSEC II
+
+
+ NSEC++ should differ from NSEC in a way that is transparent to the
+ resolver or validator.
+
+
+ Contributor: Ed Lewis
+
+
+22. Compatibility with NSEC III
+
+
+ NSEC++ should differ from NSEC as little as possible whilst achieving
+ other requirements.
+
+
+ Contributor: Alex Bligh
+
+
+23. Coexistence with NSEC
+
+
+ NSEC++ should be optional, allowing NSEC to be used instead.
+
+
+ Contributor: Ed Lewis, Alex Bligh
+
+
+24. Coexistence with NSEC II
+
+
+ NSEC++ should not impose extra work on those content with NSEC.
+
+
+ Contributor: Ed Lewis
+
+
+25. Protocol Design
+
+
+ A good security protocol would allow signing the nonexistence of some
+ selected names without revealing anything about other names.
+
+
+ Contributor: Dan Bernstein
+
+
+26. Process
+
+
+ Clearly not all of these requirements can be met. Therefore the next
+ phase of this document will be to either prioritise them or narrow
+ them down to a non-contradictory set, which should then allow us to
+ judge proposals on the basis of their fit.
+
+
+27. Acknowledgements
+
+
+28. Requirements notation
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 9]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+ document are to be interpreted as described in [RFC2119].
+
+
+29. Security Considerations
+
+
+ There are currently no security considerations called out in this
+ draft. There will be security considerations in the choice of which
+ requirements will be implemented, but there are no specific security
+ requirements during the requirements collection process.
+
+
+30. References
+
+
+30.1 Normative References
+
+
+ [dnssecbis-protocol]
+ "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
+ Month 2004.
+
+
+30.2 Informative References
+
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+ [RFC2418] Bradner, S., "IETF Working Group Guidelines and
+ Procedures", BCP 25, RFC 2418, September 1998.
+
+
+
+Authors' Addresses
+
+
+ Ben Laurie
+ Nominet
+ 17 Perryn Road
+ London W3 7LR
+ England
+
+
+ Phone: +44 (20) 8735 0686
+ EMail: ben@algroup.co.uk
+
+
+
+ Rip Loomis
+ Science Applications International Corporation
+ 7125 Columbia Gateway Drive, Suite 300
+ Columbia, MD 21046
+ US
+
+
+ EMail: gilbert.r.loomis@saic.com
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 10]
+Internet-Draft signed-nonexistence-requirements September 2004
+
+
+
+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 (2004). 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.
+
+
+
+
+
+Laurie & Loomis Expires March 2, 2005 [Page 11]
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
new file mode 100644
index 0000000..9c73c68
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
@@ -0,0 +1,1292 @@
+
+
+
+
+
+DNS Extensions Yuji Kamite
+Internet-Draft NTT Communications
+Expires: April 15, 2005 Masaya Nakayama
+ The University of Tokyo
+ October 14, 2004
+
+
+
+ TKEY Secret Key Renewal Mode
+ draft-ietf-dnsext-tkey-renewal-mode-05
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ 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 April 15, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document defines a new mode in TKEY and proposes an atomic
+ method for changing secret keys used for TSIG periodically.
+ Originally, TKEY provides methods of setting up shared secrets other
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 1]
+
+INTERNET-DRAFT October 2004
+
+
+ than manual exchange, but it cannot control timing of key renewal
+ very well though it can add or delete shared keys separately. This
+ proposal is a systematical key renewal procedure intended for
+ preventing signing DNS messages with old and non-safe keys
+ permanently.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . 4
+ 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . 4
+ 2. Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . 5
+ 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . 5
+ 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . 6
+ 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . 7
+ 2.3.1 Query for Key Renewal . . . . . . . . . . . . . . . . 7
+ 2.3.2 Response for Key Renewal . . . . . . . . . . . . . . . 7
+ 2.3.3 Attributes of Generated Key . . . . . . . . . . . . . 8
+ 2.3.4 TKEY RR structure . . . . . . . . . . . . . . . . . . 8
+ 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . 10
+ 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . 10
+ 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . 10
+ 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . 11
+ 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . 11
+ 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . 12
+ 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . 13
+ 2.6 Considerations about Non-compliant Hosts . . . . . . . . . 14
+ 3. Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 4. Compulsory Key Revocation . . . . . . . . . . . . . . . . . . 15
+ 4.1 Compulsory Key Revocation by Server . . . . . . . . . . . 15
+ 4.2 Authentication Methods Considerations . . . . . . . . . . 15
+ 5. Special Considerations for Two Servers' Case . . . . . . . . 16
+ 5.1 To Cope with Collisions of Renewal Requests . . . . . . . 16
+ 6. Key Name Considerations . . . . . . . . . . . . . . . . . . . 17
+ 7. Example Usage of Secret Key Renewal Mode . . . . . . . . . . 17
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
+ 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21
+ 11.2 Informative References . . . . . . . . . . . . . . . . . . 21
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
+ Intellectual Property and Copyright Statements . . . . . . . . 23
+
+
+
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 2]
+
+INTERNET-DRAFT October 2004
+
+
+1. Introduction
+
+ TSIG [RFC2845] provides DNS message integrity and the
+ request/transaction authentication by means of message authentication
+ codes (MAC). TSIG is a practical solution in view of calculation
+ speed and availability. However, TSIG does not have exchanging
+ mechanism of shared secret keys between server and resolver, and
+ administrators might have to exchange secret keys manually. TKEY
+ [RFC2930] is introduced to solve such problem and it can exchange
+ secrets for TSIG via networks.
+
+ In various modes of TKEY, a server and a resolver can add or delete a
+ secret key be means of TKEY message exchange. However, the existing
+ TKEY does not care fully about the management of keys which became
+ too old, or dangerous after long time usage.
+
+ It is ideal that the number of secret which a pair of hosts share
+ should be limited only one, because having too many keys for the same
+ purpose might not only be a burden to resolvers for managing and
+ distinguishing according to servers to query, but also does not seem
+ to be safe in terms of storage and protection against attackers.
+ Moreover, perhaps holding old keys long time might give attackers
+ chances to compromise by scrupulous calculation.
+
+ Therefore, when a new shared secret is established by TKEY, the
+ previous old secret should be revoked immediately. To accomplish
+ this, DNS servers must support a protocol for key renewal. This
+ document specifies procedure to refresh secret keys between two hosts
+ which is defined within the framework of TKEY, and it is called "TKEY
+ Secret Key Renewal Mode".
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+
+1.1. Defined Words
+
+ * Inception Time: Beginning of the shared secret key lifetime. This
+ value is determined when the key is generated.
+
+ * Expiry Limit: Time limit of the key's validity. This value is
+ determined when a new key is generated. After Expiry Limit, server
+ and client (resolver) must not authenticate TSIG signed with the key.
+ Therefore, Renewal to the next key should be carried out before
+ Expiry Limit.
+
+ * Partial Revocation Time: Time when server judges the key is too old
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 3]
+
+INTERNET-DRAFT October 2004
+
+
+ and must be updated. It must be between Inception Time and Expiry
+ Limit. This value is determined by server freely following its
+ security policy. e.g., If the time from Inception to Partial
+ Revocation is short, renewal will be carried out more often, which
+ might be safer.
+
+ * Revocation Time: Time when the key becomes invalid and can be
+ removed. This value is not determined in advance because it is the
+ actual time when revocation is completed.
+
+ * Adoption Time: Time when the new key is adopted as the next key
+ formally. After Adoption, the key is valid and server and client can
+ generate or verify TSIG making use of it. Adoption Time also means
+ the time when it becomes possible to remove the previous key, so
+ Revocation and Adoption are usually done at the same time.
+
+
+ Partial
+ Inception Revocation Revocation Expiry Limit
+ | | | |
+ |----------------|- - - - - - >>|- (revoked) -|
+ | | | |
+ previous key | | |
+ |- - - -|-------------------->> time
+ | | new key
+ Inception Adoption
+
+
+1.2. New Format and Assigned Numbers
+
+ TSIG
+ ERROR = (PartialRevoke), TBD
+
+ TKEY
+ Mode = (server assignment for key renewal), TBD
+ Mode = (Diffie-Hellman exchange for key renewal), TBD
+ Mode = (resolver assignment for key renewal), TBD
+ Mode = (key adoption), TBD
+
+
+1.3. Overview of Secret Key Renewal Mode
+
+ When a server receives a query from a client signed with a TSIG key,
+ It always checks if the present time is within the range of usage
+ duration it considers safe. If it is judged that the key is too old,
+ i.e., after Partial Revocation Time, the server comes to be in
+ Partial Revocation state about the key, and this key is called
+ partially revoked.
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 4]
+
+INTERNET-DRAFT October 2004
+
+
+ In this state, if a client sends a normal query (e.g., question about
+ A RR) other than TKEY Renewal request with TSIG signed with the old
+ key, the server returns an error message to notify that the time to
+ renew has come. This is called "PartialRevoke" error message. It is
+ server's choice whether it returns PartialRevoke or not. If and only
+ if the server is ready for changing its own key, it decides to return
+ PartialRevoke.
+
+ The client which got this error is able to notice that it is
+ necessary to refresh the secret. To make a new shared secret, it
+ sends a TKEY Renewal request, in which several keying methods are
+ available. It can make use of TSIG authentication signed with the
+ partially revoked key mentioned above.
+
+ After new secret establishment, the client sends a TKEY Adoption
+ request for renewal confirmation. This can also be authenticated with
+ the partially revoked key. If this is admitted by the server, the new
+ key is formally adopted, and at the same time the corresponding old
+ secret is invalidated. Then the client can send the first query again
+ signed with the new key.
+
+ Key renewal procedure is executed based on two-phase commit
+ mechanism. The first phase is the TKEY Renewal request and its
+ response, which means preparatory confirmation for key update. The
+ second phase is Adoption request and its response. If the server gets
+ request and client receives the response successfully, they can
+ finish renewal process. If any error happens and renewal process
+ fails during these phases, client should roll back to the beginning
+ of the first phase, and send TKEY Renewal request again. This
+ rollback can be done until the Expiry Limit of the key.
+
+
+2. Shared Secret Key Renewal
+
+ Suppose a server and a client agree to change their TSIG keys
+ periodically. Key renewal procedure is defined between two hosts.
+
+2.1. Key Usage Time Check
+
+ Whenever a server receives a query with TSIG and can find a key that
+ is used for signing it, the server checks its Inception Time, Partial
+ Revocation Time and Expiry Limit (this information is usually
+ memorized by the server).
+
+ When the present time is before Inception Time, the server MUST NOT
+ verify TSIG with the key, and server acts the same way as when the
+ key used by the client is not recognized. It follows [RFC2845] 4.5.1.
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 5]
+
+INTERNET-DRAFT October 2004
+
+
+ When the present time is equal to Inception Time, or between
+ Inception Time and Partial Revocation Time, the behavior of the
+ server is the same as when a valid key is found. It follows [RFC2845]
+ 4.5.2 and 4.5.3.
+
+ When the present time is the same as the Partial Revocation Time, or
+ between the Partial Revocation Time and Expiry Limit, the server
+ comes to be in Partial Revocation state about the TSIG key and
+ behaves according to the next section.
+
+ When the present time is the same as the Expiry Time or after it, the
+ server MUST NOT verify TSIG with the key, and returns error messages
+ in the same way as when the key used by the client is not recognized.
+ It follows [RFC2845] 4.5.1.
+
+
+2.2. Partial Revocation
+
+ In Partial Revocation state, we say the server has partially revoked
+ the key and the key has become a "partially revoked key".
+
+ If server has received a query signed with the partially revoked key
+ for TKEY Renewal request (See section 2.3.) or Key Adoption request
+ (See section 2.4.), then server does proper process following each
+ specification. If it is for TKEY key deletion request ([RFC2930]
+ 4.2), server MAY process usual deletion operation defined therein.
+
+ If server receives other types of query signed with the partially
+ revoked key, and both the corresponding MAC and signed TIME are
+ verified, then server begins returning answer whose TSIG error code
+ is "PartialRevoke" (See section 9.). Server MUST randomly but with
+ increasing frequency return PartialRevoke when in the Partial
+ Revocation state.
+
+ Server can decide when it actually sends PartialRevoke, checking if
+ it is appropriate time for renewal. Server MUST NOT return
+ PartialRevoke if this is apart long lived TSIG transaction (such as
+ AXFR) that started before the Partial Revocation Time.
+
+ If the client receives PartialRevoke and understands it, then it MUST
+ retry the query with the old key unless a new key has been adopted.
+ Client SHOULD start the process to renew the TSIG key. For key
+ renewal procedure, see details in Section 2.3 and 2.4.
+
+ PartialRevoke period (i.e., time while server returns PartialRevoke
+ randomely) SHOULD be small, say 2-5% of key lifetime. This is
+ server's choice.
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 6]
+
+INTERNET-DRAFT October 2004
+
+
+ Server MUST keep track of clients ignoring PartialRevoke, thus
+ indicating ignorance of this TKEY mode.
+
+ PartialRevoke error messages have the role to inform clients of the
+ keys' partial revocation and urge them to send TKEY Renewal requests.
+ These error responses MUST be signed with those partial revoked keys
+ if the queries are signed with them. They are sent only when the
+ signing keys are found to be partially revoked. If the MAC of TSIG
+ cannot be verified with the partially revoked keys, servers MUST NOT
+ return PartialRevoke error with MAC, but MUST return another error
+ such as "BADSIG" without MAC (following [RFC2845] 4.5.3); in other
+ words, a server informs its key's partial revocation only when the
+ MAC in the received query is valid.
+
+
+2.3. Key Renewal Message Exchange
+
+2.3.1. Query for Key Renewal
+
+ If a client has received a PartialRevoke error and authenticated the
+ response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
+ this document, we call it Renewal request, too.) to the server. The
+ request MUST be signed with TSIG or SIG(0) [RFC2931] for
+ authentication. If TSIG is selected, the client can sign it with the
+ partial revoked key.
+
+ Key Renewal can use one of several keying methods which is indicated
+ in "Mode" field of TKEY RR, and its message structure is dependent on
+ that method.
+
+
+2.3.2. Response for Key Renewal
+
+ The server which has received Key Renewal request first tries to
+ verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
+ verified with the partially revoked key, the request MUST be
+ authenticated.
+
+ After authentication, server must check existing old key's validity.
+ If the partially revoked key indicated in the request TKEY's OldName
+ and OldAlgorithm field (See section 2.3.4.) does not exist at the
+ server, "BADKEY" [RFC2845] is given in Error field for response. If
+ any other error happens, server returns appropriate error messages
+ following the specification described in section 2.5. If there are no
+ errors, server returns a Key Renewal answer. This answer MUST be
+ signed with TSIG or SIG(0) for authentication.
+
+ When this answer is successfully returned and no error is detected by
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 7]
+
+INTERNET-DRAFT October 2004
+
+
+ client, a new shared secret can be established. The details of
+ concrete keying procedure are given in the section 2.5.
+
+ Note:
+ Sometimes Adoption message and new Renewal request will cross on
+ the wire. In this case the newly generated key Adoption message is
+ resent.
+
+
+2.3.3. Attributes of Generated Key
+
+ As a result of this message exchange, client comes to know the newly
+ generated key's attributes such as key's name, Inception Time and
+ Expiry Limit. They are decided by the server and told to the client;
+ in particular, however, once the server has decided Expiry Limit and
+ returned a response, it should obey the decision as far as it can. In
+ other words, they SHOULD NOT change time values for checking Expiry
+ Limit in the future without any special reason, such as security
+ issue like "Emergency Compulsory Revocation" described in section 8.
+
+ On the other hand, Partial Revocation Time of this generated key is
+ not decided based on the request, and not informed to the client. The
+ server can determine any value as long as it is between Inception
+ Time and Expiry Limit. However, the period from Inception to Partial
+ Revocation SHOULD be fixed as the server side's configuration or be
+ set the same as the corresponding old key's one.
+
+ Note:
+ Even if client sends Key Renewal request though the key described
+ in OldName has not been partially revoked yet, server does renewal
+ processes. At the moment when the server accepts such requests
+ with valid authentication, it MUST forcibly consider the key is
+ already partially revoked, that is, the key's Partial Revocation
+ Time must be changed into the present time (i.e., the time when
+ the server receives the request).
+
+
+2.3.4. TKEY RR structure
+
+ TKEY RR for Key Renewal message has the structure given below. In
+ principle, format and definition for each field follows [RFC2930].
+ Note that each keying scheme sometimes needs different interpretation
+ of RDATA field; for detail, see section 2.5.
+
+ Field Type Comment
+ ------- ------ -------
+ NAME domain used for a new key, see below
+ TYPE u_int16_t (defined in [RFC2930])
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 8]
+
+INTERNET-DRAFT October 2004
+
+
+ CLASS u_int16_t (defined in [RFC2930])
+ TTL u_int32_t (defined in [RFC2930])
+ RDLEN u_int16_t (defined in [RFC2930])
+ RDATA:
+ Algorithm: domain algorithm for a new key
+ Inception: u_int32_t about the keying material
+ Expiration: u_int32_t about the keying material
+ Mode: u_int16_t scheme for key agreement
+ see section 9.
+ Error: u_int16_t see description below
+ Key Size: u_int16_t see description below
+ Key Data: octet-stream
+ Other Size: u_int16_t (defined in [RFC2930])
+ size of other data
+ Other Data: newly defined: see description below
+
+
+ For "NAME" field, both non-root and root name are allowed. It may
+ be used for a new key's name in the same manner as [RFC2930] 2.1.
+
+ "Algorithm" specifies which algorithm is used for agreed keying
+ material, which is used for identification of the next key.
+
+ "Inception" and "Expiration" are used for the valid period of
+ keying material. The meanings differ somewhat according to whether
+ the message is request or answer, and its keying scheme.
+
+ "Key Data" has different meanings according to keying schemes.
+
+ "Mode" field stores the value in accordance with the keying method,
+ and see section 2.5. Servers and clients supporting TKEY Renewal
+ method MUST implement "Diffie-Hellman exchange for key renewal"
+ scheme. All other modes are OPTIONAL.
+
+ "Error" is an extended RCODE which includes "PartialRevoke" value
+ too. See section 9.
+
+ "Other Data" field has the structure given below. They describe
+ attributes of the key to be renewed.
+
+ in Other Data filed:
+
+ Field Type Comment
+ ------- ------ -------
+ OldNAME domain name of the old key
+ OldAlgorithm domain algorithm of the old key
+
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 9]
+
+INTERNET-DRAFT October 2004
+
+
+ "OldName" indicates the name of the previous key (usually,
+ this is partially revoked key's name that client noticed by
+ PartialRevoke answer from server), and "OldAlogirthm"
+ indicates its algorithm.
+
+
+2.4. Key Adoption
+
+2.4.1. Query for Key Adoption
+
+ After receiving a TKEY Renewal answer, the client gets the same
+ secret as the server. Then, it sends a TKEY Adoption request. The
+ request's question section's QNAME field is the same as the NAME
+ filed of TKEY written below. In additional section, there is one TKEY
+ RR that has the structure and values described below.
+
+ "NAME" field is the new key's name to be adopted which was already
+ generated by Renewal message exchange. "Algorithm" is its
+ algorithm. "Inception" means the key's Inception Time, and
+ "Expiration" means Expiry Limit.
+
+ "Mode" field is the value of "key adoption". See section 9.
+
+ "Other Data" field in Adoption has the same structure as that of
+ Renewal request message. "OldName" means the previous old key, and
+ "OldAlogirthm" means its algorithm.
+
+ Key Adoption request MUST be signed with TSIG or SIG(0) for
+ authentication. The client can sign TSIG with the previous key. Note
+ that until Adoption is finished, the new key is treated as invalid,
+ thus it cannot be used for authentication immediately.
+
+
+2.4.2. Response for Key Adoption
+
+ The server which has received Adoption request, it verifies TSIG or
+ SIG(0) accompanying it. If the TSIG is signed with the partially
+ revoked key and can be verified, the message MUST be authenticated.
+
+ If the next new key indicated by the request TKEY's "NAME" is not
+ present at the server, BADNAME [RFC2845] is given in Error field and
+ the error message is returned.
+
+ If the next key exists but it has not been adopted formally yet, the
+ server confirms the previous key's existence indicated by the
+ "OldName" and "OldAlgorithm" field. If it succeeds, the server
+ executes Adoption of the next key and Revocation of the previous key.
+ Response message duplicates the request's TKEY RR with NOERROR,
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 10]
+
+INTERNET-DRAFT October 2004
+
+
+ including "OldName" and "OldAlgorithm" that indicate the revoked key.
+
+ If the next key exists but it is already adopted, the server returns
+ a response message regardless of the substance of the request TKEY's
+ "OldName". In this response, Response TKEY RR has the same data as
+ the request's one except as to its "Other Data" that is changed into
+ null (i.e., "Other Size" is zero), which is intended for telling the
+ client that the previous key name was ignored, and the new key is
+ already available.
+
+ Client sometimes has to retry Adoption request. Suppose the client
+ sent request signed with the partially revoked key, but its response
+ did not return successfully (e.g., due to the drop of UDP packet).
+ Client will probably retry Adoption request; however, the request
+ will be refused in the form of TSIG "BADKEY" error because the
+ previous key was already revoked. In this case, client will
+ retransmit Adoption request signed with the next key, and expect a
+ response which has null "Other Data" for confirming the completion of
+ renewal.
+
+
+2.5. Keying Schemes
+
+ In Renewal message exchanges, there are no limitations as to which
+ keying method is actually used. The specification of keying
+ algorithms is independent of the general procedure of Renewal that is
+ described in section 2.3.
+
+ Now this document specifies three algorithms in this section, but
+ other future documents can make extensions defining other methods.
+
+
+2.5.1. DH Exchange for Key Renewal
+
+ This scheme is defined as an extended method of [RFC2930] 4.1. This
+ specification only describes the difference from it and special
+ notice; assume that all other points, such as keying material
+ computation, are the exactly same as the specification of [RFC2930]
+ 4.1.
+
+ Query
+ In Renewal request for type TKEY with this mode, there is one TKEY
+ RR and one KEY RR in the additional information section. KEY RR is
+ the client's Diffie-Hellman public key [RFC2539].
+
+ QNAME in question section is the same as that of "NAME" field in
+ TKEY RR, i.e., it means the requested new key's name.
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 11]
+
+INTERNET-DRAFT October 2004
+
+
+ TKEY "Mode" field stores the value of "DH exchange for key
+ renewal". See section 9.
+
+ TKEY "Inception" and "Expiration" are those requested for the
+ keying material, that is, requested usage period of a new key.
+
+ TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
+
+ Response
+ The server which received this request first verifies the TSIG,
+ SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
+ old key's existence validity is checked, following section 2.3. If
+ any incompatible DH key is found in the request, "BADKEY"
+ [RFC2845] is given in Error field for response. "FORMERR" is given
+ if the query included no DH KEY.
+
+ If there are no errors, the server processes a response according
+ to Diffie-Hellman algorithm and returns the answer. In this
+ answer, there is one TKEY RR in answer section and KEY RR(s) in
+ additional section.
+
+ As long as no error has occurred, all values of TKEY are equal to
+ that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
+ Inception, Expiration, Key Size and Key Data.
+
+ TKEY "NAME" field in the answer specifies the name of newly
+ produced key which the client MUST use.
+
+ TKEY "Inception" and "Expiration" mean the periods of the produced
+ key usage. "Inception" is set to be the time when the new key is
+ actually generated or the time before it, and it will be regarded
+ as Inception Time. "Expiration" is determined by the server, and
+ it will be regarded as Expiry Limit.
+
+ TKEY "Key Data" is used as an additional nonce, following
+ [RFC2930] 4.1.
+
+ The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
+ the additional section and a server Diffie-Hellman KEY RR will
+ also be present in the answer section, following [RFC2930] 4.1.
+
+
+2.5.2. Server Assigned Keying for Key Renewal
+
+ This scheme is defined as an extended method of [RFC2930] 4.4. This
+ specification only describes the difference from it and special
+ notice; assume that all other points, such as secret encrypting
+ method, are the exactly same as the specification of [RFC2930] 4.4.
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 12]
+
+INTERNET-DRAFT October 2004
+
+
+ Query
+ In Renewal request for type TKEY with this mode, there is one TKEY
+ RR and one KEY RR in the additional information section. KEY RR is
+ used in encrypting the response.
+
+ QNAME in question section is the same as that of "NAME" field in
+ TKEY RR, i.e., it means the requested new key's name.
+
+ TKEY "Mode" field stores the value of "server assignment for key
+ renewal". See section 9.
+
+ TKEY "Inception" and "Expiration" are those requested for the
+ keying material, that is, requested usage period of a new key.
+
+ TKEY "Key Data" is provided following the specification of
+ [RFC2930] 4.4.
+
+ Response
+ The server which received this request first verifies the TSIG,
+ SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
+ old key's existence validity is checked, following section 2.3.
+ "FORMERR" is given if the query specified no encryption key.
+
+ If there are no errors, the server response contains one TKEY RR
+ in the answer section, and echoes the KEY RR provided in the query
+ in the additional information section.
+
+ TKEY "NAME" field in the answer specifies the name of newly
+ produced key which the client MUST use.
+
+ TKEY "Inception" and "Expiration" mean the periods of the produced
+ key usage. "Inception" is set to be the time when the new key is
+ actually generated or the time before it, and it will be regarded
+ as Inception Time. "Expiration" is determined by the server, and
+ it will be regarded as Expiry Limit.
+
+ TKEY "Key Data" is the assigned keying data encrypted under the
+ public key in the resolver provided KEY RR, which is the same as
+ [RFC2930] 4.4.
+
+
+2.5.3. Resolver Assigned Keying for Key Renewal
+
+ This scheme is defined as an extended method of [RFC2930] 4.5. This
+ specification only describes the difference from it and special
+ notice; assume that all other points, such as secret encrypting
+ method, are the exactly same as the specification of [RFC2930] 4.5.
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 13]
+
+INTERNET-DRAFT October 2004
+
+
+ Query
+ In Renewal request for type TKEY with this mode, there is one TKEY
+ RR and one KEY RR in the additional information section. TKEY RR
+ has the encrypted keying material and KEY RR is the server public
+ key used to encrypt the data.
+
+ QNAME in question section is the same as that of "NAME" field in
+ TKEY RR, i.e., it means the requested new key's name.
+
+ TKEY "Mode" field stores the value of "resolver assignment for key
+ renewal". See section 9.
+
+ TKEY "Inception" and "Expiration" are those requested for the
+ keying material, that is, requested usage period of a new key.
+
+ TKEY "Key Data" is the encrypted keying material.
+
+ Response
+ The server which received this request first verifies the TSIG,
+ SIG(0) or DNSSEC lookup of KEY RR used. After authentication, the
+ old key's existence validity is checked, following section 2.3.
+ "FORMERR" is given if the server does not have the corresponding
+ private key for the KEY RR that was shown sin the request.
+
+ If there are no errors, the server returns a response. The
+ response contains a TKEY RR in the answer section to tell the
+ shared key's name and its usage time values.
+
+ TKEY "NAME" field in the answer specifies the name of newly
+ produced key which the client MUST use.
+
+ TKEY "Inception" and "Expiration" mean the periods of the produced
+ key usage. "Inception" is set to be the time when the new key is
+ actually generated or the time before it, and it will be regarded
+ as Inception Time. "Expiration" is determined by the server, and
+ it will be regarded as Expiry Limit.
+
+
+2.6. Considerations about Non-compliant Hosts
+
+ Key Renewal requests and responses must be exchanged between hosts
+ which can understand them and do proper processes. PartialRevoke
+ error messages will be only ignored if they should be returned to
+ non-compliant hosts.
+
+ Note that server does not inform actively the necessity of renewal to
+ clients, but inform it as responses invoked by client's query.
+ Server needs not care whether the PartialRevoke errors has reached
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 14]
+
+INTERNET-DRAFT October 2004
+
+
+ client or not. If client has not received yet because of any reasons
+ such as packet drops, it will resend the queries, and finally will be
+ able to get PartialRevoke information.
+
+
+3. Secret Storage
+
+ Every server keeps all secrets and attached information, e.g.,
+ Inception Time, Expiry Limit, etc. safely to be able to recover from
+ unexpected stop. To accomplish this, formally adopted keys SHOULD be
+ memorized not only on memory, but also be stored in the form of some
+ files. It will become more secure if they are stored in ecrypted
+ form.
+
+
+4. Compulsory Key Revocation
+
+4.1. Compulsory Key Revocation by Server
+
+ There is a rare but possible case that although servers have already
+ partially revoked keys, clients do not try to send any Renewal
+ requests. If this state continues, in the future it will become the
+ time of Expiry Limit. After Expiry Limit, the keys will be expired
+ and completely removed, so this is called Compulsory Key Revocation
+ by server.
+
+ If Expiry Limit is too distant from the Partial Revocation Time, then
+ even though very long time passes, clients will be able to refresh
+ secrets only if they add TSIG signed with those old partially revoked
+ keys into requests, which is not safe.
+
+ On the other hand, if Expiry Limit is too close to Partial Revocation
+ Time, perhaps clients might not be able to notice their keys' Partial
+ Revocation by getting "PartialRevoke" errors.
+
+ Therefore, servers should set proper Expiry Limit to their keys,
+ considering both their keys' safety, and enough time for clients to
+ send requests and process renewal.
+
+
+4.2. Authentication Methods Considerations
+
+ It might be ideal to provide both SIG(0) and TSIG as authentication
+ methods. For example:
+
+ A client and a server start SIG(0) authentication at first, to
+ establish TSIG shared keys by means of "Query for Diffie-Hellman
+ Exchanged Keying" as described in [RFC2930] 4.1. Once they get
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 15]
+
+INTERNET-DRAFT October 2004
+
+
+ shared secret, they keep using TSIG for queries and responses.
+ After a while the server returns a "ParitalRevoke" error and they
+ begin a key renewal process. Both TSIG signed with partially
+ revoked keys and SIG(0) are okay for authentication, but TSIG would
+ be easier to use considering calculation efficiency.
+
+ Suppose now client is halted for long time with some reason.
+ Because server does not execute any renewal process, it will
+ finally do Compulsory Revocation. Even if client restarts and sends
+ a key Renewal request, it will fail because old key is already
+ deleted at server.
+
+ At this moment, however, if client also uses SIG(0) as another
+ authentication method, it can make a new shared key again and
+ recover successfully by sending "Query for Diffie-Hellman Exchanged
+ Keying" with SIG(0).
+
+
+5. Special Considerations for Two servers' Case
+
+ This section refers to the case where both hosts are DNS servers
+ which can act as full resolvers as well and using one shared key
+ only. If one server (called Server A) wants to refresh a shared key
+ (called "Key A-B"), it will await a TKEY Renewal request from the
+ other server (called Server B). However, perhaps Server A wants to
+ refresh the key right now.
+
+ In this case, Server A is allowed to send a Renewal request to Server
+ B, if Server A knows the Key A-B is too old and wants to renew it
+ immediately.
+
+ Note that the initiative in key renewal belongs to Server A because
+ it can notice the Partial Revocation Time and decide key renewal. If
+ Server B has information about Partial Revocation Time as well, it
+ can also decide for itself to send Renewal request to Server A.
+ However, it is not essential for both two servers have information
+ about key renewal timing.
+
+5.1. To Cope with Collisions of Renewal Requests
+
+ At least one of two hosts which use Key Renewal must know their key
+ renewal information such as Partial Revocation Time. It is okay that
+ both hosts have it.
+
+ Provided that both two servers know key renewal timing information,
+ there is possibility for them to begin partial revocation and sending
+ Renewal requests to each other at the same time. Such collisions will
+ not happen so often because Renewal requests are usually invoked when
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 16]
+
+INTERNET-DRAFT October 2004
+
+
+ hosts want to send queries, but it is possible.
+
+ When one of two servers tries to send Renewal requests, it MUST
+ protect old secrets that it has partially revoked and prevent it from
+ being refreshed by any requests from the other server (i.e., it must
+ lock the old secret during the process of renewal). While the server
+ is sending Renewal requests and waiting responses, it ignores the
+ other server's Renewal requests.
+
+ Therefore, servers might fail to change secrets by means of their own
+ requests to others. After failure they will try to resend, but they
+ should wait for random delays by the next retries. If they get any
+ Renewal requests from others while they are waiting, their shared
+ keys may be refreshed, then they do not need to send any Renewal
+ requests now for themselves.
+
+
+6. Key Name Considerations
+
+ Since both servers and clients have only to distinguish new secrets
+ and old ones, keys' names do not need to be specified strictly.
+ However, it is recommended that some serial number or key generation
+ time be added to the name and that the names of keys between the same
+ pair of hosts should have some common labels among their keys. For
+ example, suppose A.example.com. and B.example.com. share the key
+ "<serial number>.A.example.com.B.example.com." such as
+ "10010.A.example.com.B.example.com.". After key renewal, they change
+ their secret and name into "10011.A.example.com.B.example.com."
+
+ Servers and clients must be able to use keys properly for each query.
+ Because TSIG secret keys themselves do not have any particular IDs to
+ be distinguished and would be identified by their names and
+ algorithm, it must be understood correctly what keys are refreshed.
+
+
+7. Example Usage of Secret Key Renewal Mode
+
+ This is an example of Renewal mode usage where a Server,
+ server.example.com, and a Client, client.exmple.com have an initial
+ shared secret key named "00.client.example.com.server.example.com".
+
+ (1) The time values for key
+ "00.client.example.com.server.example.com" was set as follows:
+ Inception Time is at 1:00, Expiry Limit is at 21:00.
+
+ (2) At Server, renewal time has been set: Partial Revocation Time
+ is at 20:00.
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 17]
+
+INTERNET-DRAFT October 2004
+
+
+ (3) Suppose the present time is 19:55. If Client sends a query
+ signed with key "00.client.example.com.server.example.com" to ask
+ the IP address of "www.example.com", finally it will get a proper
+ answer from Server with valid TSIG (NOERROR).
+
+ (4) At 20:05. Client sends a query to ask the IP address of
+ "www2.example.com". It is signed with key
+ "00.client.example.com.server.example.com". Server returns an
+ answer for the IP address. However, server has begun retuning
+ PartialRevoke Error randomely. This answer includes valid TSIG MAC
+ signed with "00.client.example.com.server.example.com", and its
+ Error Code indicates PartialRevoke. Client understands that the
+ current key is partially revoked.
+
+ (5) At 20:06. Client sends a Renewal request to Server. This
+ request is signed with key
+ "00.client.example.com.server.example.com". It includes data such
+ as:
+
+ Question Section:
+ QNAME = 01.client.example.com. (Client can set this freely)
+ TYPE = TKEY
+
+ Additional Section:
+ 01.client.example.com. TKEY
+ Algorithm = hmac-md5-sig-alg.reg.int.
+ Inception = (value meaning 20:00)
+ Expiration = (value meaning next day's 16:00)
+ Mode = (DH exchange for key renewal)
+ OldName = 00.client.example.com.server.example.com.
+ OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+ Additional Section also contains a KEY RR for DH and a TSIG RR.
+
+ (6) As soon as Server receives this request, it verifies TSIG. It
+ is signed with the partially revoked key
+ "00.client.example.com.server.example.com". and Server accepts the
+ request. It creates a new key by Diffie-Hellman calculation and
+ returns an answer which includes data such as:
+
+ Answer Section:
+ 01.client.example.com.server.example.com. TKEY
+ Algorithm = hmac-md5-sig-alg.reg.int.
+ Inception = (value meaning 20:00)
+ Expiration = (value meaning next day's 16:00)
+ Mode = (DH exchange for key renewal)
+ OldName = 00.client.example.com.server.example.com.
+ OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 18]
+
+INTERNET-DRAFT October 2004
+
+
+ Answer Section also contains KEY RRs for DH.
+
+ Additional Section also contains a TSIG RR.
+ This response is signed with key
+ "00.client.example.com.server.example.com" without error.
+
+ At the same time, Server decides to set the Partial Revocation Time
+ of this new key "01.client.example.com.server.example.com." as next
+ day's 15:00.
+
+ (7) Client gets the response and checks TSIG MAC, and calculates
+ Diffie-Hellman. It will get a new key, and it has been named
+ "01.client.example.com.server.example.com" by Server.
+
+ (8) At 20:07. Client sends an Adoption request to Server. This
+ request is signed with the previous key
+ "00.client.example.com.server.example.com". It includes:
+
+ Question Section:
+ QNAME = 01.client.example.com.server.example.com.
+ TYPE = TKEY
+
+ Additional Section:
+ 01.client.example.com.server.example.com. TKEY
+ Algorithm = hmac-md5-sig-alg.reg.int.
+ Inception = (value meaning 20:00)
+ Expiration = (value meaning next day's 16:00)
+ Mode = (key adoption)
+ OldName = 00.client.example.com.server.example.com.
+ OldAlgorithm = hmac-md5-sig-alg.reg.int.
+
+ Additional Section also contains a TSIG RR.
+
+ (9) Server verifies the query's TSIG. It is signed with the
+ previous key and authenticated. It returns a response whose TKEY RR
+ is the same as the request's one. The response is signed with key
+ "00.client.example.com.server.example.com.". As soon as the
+ response is sent, Server revokes and removes the previous key. At
+ the same time, key "01.client.example.com.server.example.com." is
+ validated.
+
+ (10) Client acknowledges the success of Adoption by receiving the
+ response. Then, it retries to send an original question about
+ "www2.example.com". It is signed with the adopted key
+ "01.client.example.com.server.example.com", so Server authenticates
+ it and returns an answer.
+
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 19]
+
+INTERNET-DRAFT October 2004
+
+
+ (11) This key is used until next day's 15:00. After that, it will
+ be partially revoked again.
+
+
+8. Security Considerations
+
+ This document considers about how to refresh shared secret. Secret
+ changed by this method is used at servers in support of TSIG
+ [RFC2845].
+
+ [RFC2104] says that current attacks to HMAC do not indicate a
+ specific recommended frequency for key changes but periodic key
+ refreshment is a fundamental security practice that helps against
+ potential weaknesses of the function and keys, and limits the damage
+ of an exposed key. TKEY Secret Key Renewal provides the method of
+ periodical key refreshment.
+
+ In TKEY Secret Key Renewal, clients need to send two requests
+ (Renewal and Adoption) and spend time to finish their key renewal
+ processes. Thus the usage period of secrets should be considered
+ carefully based on both TKEY processing performance and security.
+
+ This document specifies the procedure of periodical key renewal, but
+ actually there is possibility for servers to have no choice other
+ than revoking their secret keys immediately especially when the keys
+ are found to be compromised by attackers. This is called "Emergency
+ Compulsory Revocation". For example, suppose the original Expiry
+ Limit was set at 21:00, Partial Revocation Time at 20:00 and
+ Inception Time at 1:00. if at 11:00 the key is found to be
+ compromised, the server sets Expiry Limit forcibly to be 11:00 or
+ before it.
+
+ Consequently, once Compulsory Revocation (See section 4.) is carried
+ out, normal renewal process described in this document cannot be done
+ any more as far as the key is concerned. However, after such
+ accidents happened, the two hosts are able to establish secret keys
+ and begin renewal procedure only if they have other (non-compromised)
+ shared TSIG keys or safe SIG(0) keys for the authentication of
+ initial secret establishment such as Diffie-Hellman Exchanged Keying.
+
+
+9. IANA Considerations
+
+ IANA needs to allocate a value for "DH exchange for key renewal",
+ "server assignment for key renewal", "resolver assignment for key
+ renewal" and "key adoption" in the mode filed of TKEY. It also needs
+ to allocate a value for "PartialRevoke" from the extended RCODE
+ space.
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 20]
+
+INTERNET-DRAFT October 2004
+
+
+10. Acknowledgements
+
+ The authors would like to thank Olafur Gudmundsson, whose helpful
+ input and comments contributed greatly to this document.
+
+
+11. References
+
+11.1. Normative References
+
+[RFC2119]
+ Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+[RFC2539]
+ D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
+ System (DNS)", RFC 2539, March 1999.
+
+[RFC2845]
+ Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+ "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
+ May 2000.
+
+[RFC2930]
+ D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
+ RFC 2930, September 2000.
+
+[RFC2931]
+ D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
+ )", RFC 2931, September 2000.
+
+11.2. Informative References
+
+[RFC2104]
+ H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
+ Authentication", RFC2104, February 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 21]
+
+INTERNET-DRAFT October 2004
+
+
+Authors' Addresses
+
+ Yuji Kamite
+ NTT Communications Corporation
+ Tokyo Opera City Tower
+ 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo
+ 163-1421, Japan
+ EMail: y.kamite@ntt.com
+
+
+ Masaya Nakayama
+ Information Technology Center, The University of Tokyo
+ 2-11-16 Yayoi, Bunkyo-ku, Tokyo
+ 113-8658, Japan
+ EMail: nakayama@nc.u-tokyo.ac.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 22]
+
+INTERNET-DRAFT October 2004
+
+
+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 (2004). 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.
+
+
+
+
+Kamite, et. al. Expires April 15, 2005 [Page 23]
+
+
+
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
new file mode 100644
index 0000000..a598826
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
@@ -0,0 +1,1501 @@
+Network Working Group J. Ihren
+Internet-Draft Autonomica AB
+Expires: April 18, 2005 O. Kolkman
+ RIPE NCC
+ B. Manning
+ EP.net
+ October 18, 2004
+
+
+
+ An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
+ DNSSEC Trust Anchors.
+ draft-ietf-dnsext-trustupdate-threshold-00
+
+
+Status of this Memo
+
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+
+ 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 April 18, 2005.
+
+
+Copyright Notice
+
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+
+Abstract
+
+
+ The DNS Security Extensions (DNSSEC) works by validating so called
+ chains of authority. The start of these chains of authority are
+ usually public keys that are anchored in the DNS clients. These keys
+ are known as the so called trust anchors.
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 1]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ This memo describes a method how these client trust anchors can be
+ replaced using the DNS validation and querying mechanisms (in-band)
+ when the key pairs used for signing by zone owner are rolled.
+
+
+ This memo also describes a method to establish the validity of trust
+ anchors for initial configuration, or priming, using out of band
+ mechanisms.
+
+
+Table of Contents
+
+
+ 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1 Key Signing Keys, Zone Signing Keys and Secure Entry
+ Points . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Introduction and Background . . . . . . . . . . . . . . . . . 5
+ 2.1 Dangers of Stale Trust Anchors . . . . . . . . . . . . . . 5
+ 3. Threshold-based Trust Anchor Rollover . . . . . . . . . . . . 7
+ 3.1 The Rollover . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2 Threshold-based Trust Update . . . . . . . . . . . . . . . 8
+ 3.3 Possible Trust Update States . . . . . . . . . . . . . . . 9
+ 3.4 Implementation notes . . . . . . . . . . . . . . . . . . . 10
+ 3.5 Possible transactions . . . . . . . . . . . . . . . . . . 11
+ 3.5.1 Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
+ 3.5.2 Addition of a new DNSKEY (no removal) . . . . . . . . 12
+ 3.5.3 Removal of old DNSKEY (no addition) . . . . . . . . . 12
+ 3.5.4 Multiple DNSKEYs replaced . . . . . . . . . . . . . . 12
+ 3.6 Removal of trust anchors for a trust point . . . . . . . . 12
+ 3.7 No need for resolver-side overlap of old and new keys . . 13
+ 4. Bootstrapping automatic rollovers . . . . . . . . . . . . . . 14
+ 4.1 Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.1.1 Bootstrapping trust anchors using a priming key . . . 14
+ 4.1.2 Distribution of priming keys . . . . . . . . . . . . . 15
+ 5. The Threshold Rollover Mechanism vs Priming . . . . . . . . . 16
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
+ 6.1 Threshold-based Trust Update Security Considerations . . . 17
+ 6.2 Priming Key Security Considerations . . . . . . . . . . . 17
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 20
+ 8.2 Informative References . . . . . . . . . . . . . . . . . . . 20
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
+ A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
+ B. Document History . . . . . . . . . . . . . . . . . . . . . . . 23
+ B.1 prior to version 00 . . . . . . . . . . . . . . . . . . . 23
+ B.2 version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23
+ Intellectual Property and Copyright Statements . . . . . . . . 24
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 2]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+1. Terminology
+
+
+ The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+ and "MAY" in this document are to be interpreted as described in
+ RFC2119 [1].
+
+
+ The term "zone" refers to the unit of administrative control in the
+ Domain Name System. In this document "name server" denotes a DNS
+ name server that is authoritative (i.e. knows all there is to know)
+ for a DNS zone. A "zone owner" is the entity responsible for signing
+ and publishing a zone on a name server. The terms "authentication
+ chain", "bogus", "trust anchors" and "Island of Security" are defined
+ in [4]. Throughout this document we use the term "resolver" to mean
+ "Validating Stub Resolvers" as defined in [4].
+
+
+ We use the term "security apex" as the zone for which a trust anchor
+ has been configured (by validating clients) and which is therefore,
+ by definition, at the root of an island of security. The
+ configuration of trust anchors is a client side issue. Therefore a
+ zone owner may not always know if their zone has become a security
+ apex.
+
+
+ A "stale anchor" is a trust anchor (a public key) that relates to a
+ key that is not used for signing. Since trust anchors indicate that
+ a zone is supposed to be secure a validator will mark the all data in
+ an island of security as bogus when all trust anchors become stale.
+
+
+ It is assumed that the reader is familiar with public key
+ cryptography concepts [REF: Schneier Applied Cryptography] and is
+ able to distinguish between the private and public parts of a key
+ based on the context in which we use the term "key". If there is a
+ possible ambiguity we will explicitly mention if a private or a
+ public part of a key is used.
+
+
+ The term "administrator" is used loosely throughout the text. In
+ some cases an administrator is meant to be a person, in other cases
+ the administrator may be a process that has been delegated certain
+ responsibilities.
+
+
+1.1 Key Signing Keys, Zone Signing Keys and Secure Entry Points
+
+
+ Although the DNSSEC protocol does not make a distinction between
+ different keys the operational practice is that a distinction is made
+ between zone signing keys and key signing keys. A key signing key is
+ used to exclusively sign the DNSKEY Resource Record (RR) set at the
+ apex of a zone and the zone signing keys sign all the data in the
+ zone (including the DNSKEY RRset at the apex).
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 3]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ Keys that are intended to be used as the start of the authentication
+ chain for a particular zone, either because they are pointed to by a
+ parental DS RR or because they are configured as a trust anchor, are
+ called Secure Entry Point (SEP) keys. In practice these SEP keys
+ will be key signing keys.
+
+
+ In order for the mechanism described herein to work the keys that are
+ intended to be used as secure entry points MUST have the SEP [2] flag
+ set. In the examples it is assumed that keys with the SEP flag set
+ are used as key signing keys and thus exclusively sign the DNSKEY
+ RRset published at the apex of the zone.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 4]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+2. Introduction and Background
+
+
+ When DNSSEC signatures are validated the resolver constructs a chain
+ of authority from a pre-configured trust anchor to the DNSKEY
+ Resource Record (RR), which contains the public key that validates
+ the signature stored in an RRSIG RR. DNSSEC is designed so that the
+ administrator of a resolver can validate data in multiple islands of
+ security by configuring multiple trust anchors.
+
+
+ It is expected that resolvers will have more than one trust anchor
+ configured. Although there is no deployment experience it is not
+ unreasonable to expect resolvers to be configured with a number of
+ trust anchors that varies between order 1 and order 1000. Because
+ zone owners are expected to roll their keys, trust anchors will have
+ to be maintained (in the resolver end) in order not to become stale.
+
+
+ Since there is no global key maintenance policy for zone owners and
+ there are no mechanisms in the DNS to signal the key maintenance
+ policy it may be very hard for resolvers administrators to keep their
+ set of trust anchors up to date. For instance, if there is only one
+ trust anchor configured and the key maintenance policy is clearly
+ published, through some out of band trusted channel, then a resolver
+ administrator can probably keep track of key rollovers and update the
+ trust anchor manually. However, with an increasing number of trust
+ anchors all rolled according to individual policies that are all
+ published through different channels this soon becomes an
+ unmanageable problem.
+
+
+2.1 Dangers of Stale Trust Anchors
+
+
+ Whenever a SEP key at a security apex is rolled there exists a danger
+ that "stale anchors" are created. A stale anchor is a trust anchor
+ (i.e. a public key configured in a validating resolver) that relates
+ to a private key that is no longer used for signing.
+
+
+ The problem with a stale anchors is that they will (from the
+ validating resolvers point of view) prove data to be false even
+ though it is actually correct. This is because the data is either
+ signed by a new key or is no longer signed and the resolver expects
+ data to be signed by the old (now stale) key.
+
+
+ This situation is arguably worse than not having a trusted key
+ configured for the secure entry point, since with a stale key no
+ lookup is typically possible (presuming that the default
+ configuration of a validating recursive nameserver is to not give out
+ data that is signed but failed to verify.
+
+
+ The danger of making configured trust anchors become stale anchors
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 5]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ may be a reason for zone owners not to roll their keys. If a
+ resolver is configured with many trust anchors that need manual
+ maintenance it may be easy to not notice a key rollover at a security
+ apex, resulting in a stale anchor.
+
+
+ In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
+ track key rollovers and modify the configured trust anchors
+ accordingly. The mechanism is stateless and does not need protocol
+ extensions. The proposed design is that this mechanism is
+ implemented as a "trust updating machine" that is run entirely
+ separate from the validating resolver except that the trust updater
+ will have influence over the trust anchors used by the latter.
+
+
+ In Section 4 we describe a method [Editors note: for now only the
+ frame work and a set of requirements] to install trust anchors. This
+ method can be used at first configuration or when the trust anchors
+ became stale (typically due to a failure to track several rollover
+ events).
+
+
+ The choice for which domains trust anchors are to be configured is a
+ local policy issue. So is the choice which trust anchors has
+ prevalence if there are multiple chains of trust to a given piece of
+ DNS data (e.g. when a parent zone and its child both have trust
+ anchors configured). Both issues are out of the scope of this
+ document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 6]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+3. Threshold-based Trust Anchor Rollover
+
+
+3.1 The Rollover
+
+
+ When a key pair is replaced all signatures (in DNSSEC these are the
+ RRSIG records) created with the old key will be replaced by new
+ signatures created by the new key. Access to the new public key is
+ needed to verify these signatures.
+
+
+ Since zone signing keys are in "the middle" of a chain of authority
+ they can be verified using the signature made by a key signing key.
+ Rollover of zone signing keys is therefore transparent to validators
+ and requires no action in the validator end.
+
+
+ But if a key signing key is rolled a resolver can determine its
+ authenticity by either following the authorization chain from the
+ parents DS record, an out-of-DNS authentication mechanism or by
+ relying on other trust anchors known for the zone in which the key is
+ rolled.
+
+
+ The threshold trust anchor rollover mechanism (or trust update),
+ described below, is based on using existing trust anchors to verify a
+ subset of the available signatures. This is then used as the basis
+ for a decision to accept the new keys as valid trust anchors.
+
+
+ Our example pseudo zone below contains a number of key signing keys
+ numbered 1 through Y and two zone signing keys A and B. During a key
+ rollover key 2 is replaced by key Y+1. The zone content changes
+ from:
+
+
+ example.com. DNSKEY key1
+ example.com. DNSKEY key2
+ example.com. DNSKEY key3
+ ...
+ example.com. DNSKEY keyY
+
+
+ example.com. DNSKEY keyA
+ example.com. DNSKEY keyB
+
+
+ example.com. RRSIG DNSKEY ... (key1)
+ example.com. RRSIG DNSKEY ... (key2)
+ example.com. RRSIG DNSKEY ... (key3)
+ ...
+ example.com. RRSIG DNSKEY ... (keyY)
+ example.com. RRSIG DNSKEY ... (keyA)
+ example.com. RRSIG DNSKEY ... (keyB)
+
+
+ to:
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 7]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ example.com. DNSKEY key1
+ example.com. DNSKEY key3
+ ...
+ example.com. DNSKEY keyY
+ example.com. DNSKEY keyY+1
+
+
+ example.com. RRSIG DNSKEY ... (key1)
+ example.com. RRSIG DNSKEY ... (key3)
+ ...
+ example.com. RRSIG DNSKEY ... (keyY)
+ example.com. RRSIG DNSKEY ... (keyY+1)
+ example.com. RRSIG DNSKEY ... (keyA)
+ example.com. RRSIG DNSKEY ... (keyB)
+
+
+ When the rollover becomes visible to the verifying stub resolver it
+ will be able to verify the RRSIGs associated with key1, key3 ...
+ keyY. There will be no RRSIG by key2 and the RRSIG by keyY+1 will
+ not be used for validation, since that key is previously unknown and
+ therefore not trusted.
+
+
+ Note that this example is simplified. Because of operational
+ considerations described in [5] having a period during which the two
+ key signing keys are both available is necessary.
+
+
+3.2 Threshold-based Trust Update
+
+
+ The threshold-based trust update algorithm applies as follows. If
+ for a particular secure entry point
+ o if the DNSKEY RRset in the zone has been replaced by a more recent
+ one (as determined by comparing the RRSIG inception dates)
+ and
+ o if at least M configured trust anchors directly verify the related
+ RRSIGs over the new DNSKEY RRset
+ and
+ o the number of configured trust anchors that verify the related
+ RRSIGs over the new DNSKEY RRset exceed a locally defined minimum
+ number that should be greater than one
+ then all the trust anchors for the particular secure entry point are
+ replaced by the set of keys from the zones DNSKEY RRset that have the
+ SEP flag set.
+
+
+ The choices for the rollover acceptance policy parameter M is left to
+ the administrator of the resolver. To be certain that a rollover is
+ accepted up by resolvers using this mechanism zone owners should roll
+ as few SEP keys at a time as possible (preferably just one). That
+ way they comply to the most strict rollover acceptance policy of
+ M=N-1.
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 8]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ The value of M has an upper bound, limited by the number of of SEP
+ keys a zone owner publishes (i.e. N). But there is also a lower
+ bound, since it will not be safe to base the trust in too few
+ signatures. The corner case is M=1 when any validating RRSIG will be
+ sufficient for a complete replacement of the trust anchors for that
+ secure entry point. This is not a recommended configuration, since
+ that will allow an attacker to initiate rollover of the trust anchors
+ himself given access to just one compromised key. Hence M should in
+ be strictly larger than 1 as shown by the third requirement above.
+
+
+ If the rollover acceptance policy is M=1 then the result for the
+ rollover in our example above should be that the local database of
+ trust anchors is updated by removing key "key2" from and adding key
+ "keyY+1" to the key store.
+
+
+3.3 Possible Trust Update States
+
+
+ We define five states for trust anchor configuration at the client
+ side.
+ PRIMING: There are no trust anchors configured. There may be priming
+ keys available for initial priming of trust anchors.
+ IN-SYNC: The set of trust anchors configured exactly matches the set
+ of SEP keys used by the zone owner to sign the zone.
+ OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
+ set of SEP keys used by the zone owner to sign the zone but there
+ are enough SEP key in use by the zone owner that is also in the
+ trust anchor configuration.
+ UNSYNCABLE: There is not enough overlap between the configured trust
+ anchors and the set of SEP keys used to sign the zone for the new
+ set to be accepted by the validator (i.e. the number of
+ signatures that verify is not sufficient).
+ STALE: There is no overlap between the configured trust anchors and
+ the set of SEP keys used to sign the zone. Here validation of
+ data is no longer possible and hence we are in a situation where
+ the trust anchors are stale.
+
+
+ Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of
+ the automatic trust update mechanism. The PRIMING state is where a
+ validator is located before acquiring an up-to-date set of trust
+ anchors. The transition from PRIMING to IN-SYNC is manual (see
+ Section 4 below).
+
+
+ Example: assume a secure entry point with four SEP keys and a
+ validator with the policy that it will accept any update to the set
+ of trust anchors as long as no more than two signatures fail to
+ validate (i.e. M >= N-2) and at least two signature does validate
+ (i.e. M >= 2). In this case the rollover of a single key will move
+ the validator from IN-SYNC to OUT-OF-SYNC. When the trust update
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 9]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ state machine updates the trust anchors it returns to state IN-SYNC.
+
+
+ If if for some reason it fails to update the trust anchors then the
+ next rollover (of a different key) will move the validator from
+ OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys
+ that are configured as trust anchors and that is sufficient to accpt
+ an automatic update of the trust anchors.
+
+
+ The UNSYNCABLE state is where a validator is located if it for some
+ reason fails to incorporate enough updates to the trust anchors to be
+ able to accept new updates according to its local policy. In this
+ example (i.e. with the policy specified above) this will either be
+ because M < N-2 or M < 2, which does not suffice to authenticate a
+ successful update of trust anchors.
+
+
+ Continuing with the previous example where two of the four SEP keys
+ have already rolled, but the validator has failed to update the set
+ of trust anchors. When the third key rolls over there will only be
+ one trust anchor left that can do successful validation. This is not
+ sufficient to enable automatic update of the trust anchors, hence the
+ new state is UNSYNCABLE. Note, however, that the remaining
+ up-to-date trust anchor is still enough to do successful validation
+ so the validator is still "working" from a DNSSEC point of view.
+
+
+ The STALE state, finally, is where a validator ends up when it has
+ zero remaining current trust anchors. This is a dangerous state,
+ since the stale trust anchors will cause all validation to fail. The
+ escape is to remove the stale trust anchors and thereby revert to the
+ PRIMING state.
+
+
+3.4 Implementation notes
+
+
+ The DNSSEC protocol specification ordains that a DNSKEY to which a DS
+ record points should be self-signed. Since the keys that serve as
+ trust anchors and the keys that are pointed to by DS records serve
+ the same purpose, they are both secure entry points, we RECOMMEND
+ that zone owners who want to facilitate the automated rollover scheme
+ documented herein self-sign DNSKEYs with the SEP bit set and that
+ implementation check that DNSKEYs with the SEP bit set are
+ self-signed.
+
+
+ In order to maintain a uniform way of determining that a keyset in
+ the zone has been replaced by a more recent set the automatic trust
+ update machine SHOULD only accept new DNSKEY RRsets if the
+ accompanying RRSIGs show a more recent inception date than the
+ present set of trust anchors. This is also needed as a safe guard
+ against possible replay attacks where old updates are replayed
+ "backwards" (i.e. one change at a time, but going in the wrong
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 10]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ direction, thereby luring the validator into the UNSYNCABLE and
+ finally STALE states).
+
+
+ In order to be resilient against failures the implementation should
+ collect the DNSKEY RRsets from (other) authoritative servers if
+ verification of the self signatures fails.
+
+
+ The threshold-based trust update mechanism SHOULD only be applied to
+ algorithms, as represented in the algorithm field in the DNSKEY/RRSIG
+ [3], that the resolver is aware of. In other words the SEP keys of
+ unknown algorithms should not be used when counting the number of
+ available signatures (the N constant) and the SEP keys of unknown
+ algorithm should not be entered as trust anchors.
+
+
+ When in state UNSYNCABLE or STALE manual intervention will be needed
+ to return to the IN-SYNC state. These states should be flagged. The
+ most appropriate action is human audit possibly followed by
+ re-priming (Section 4) the keyset (i.e. manual transfer to the
+ PRIMING state through removal of the configured trust anchors).
+
+
+ An implementation should regularly probe the the authoritative
+ nameservers for new keys. Since there is no mechanism to publish
+ rollover frequencies this document RECOMMENDS zone owners not to roll
+ their key signing keys more often than once per month and resolver
+ administrators to probe for key rollsovers (and apply the threshold
+ criterion for acceptance of trust update) not less often than once
+ per month. If the rollover frequency is higher than the probing
+ frequency then trust anchors may become stale. The exact relation
+ between the frequencies depends on the number of SEP keys rolled by
+ the zone owner and the value M configured by the resolver
+ administrator.
+
+
+ In all the cases below a transaction where the threshold criterion is
+ not satisfied should be considered bad (i.e. possibly spoofed or
+ otherwise corrupted data). The most appropriate action is human
+ audit.
+
+
+ There is one case where a "bad" state may be escaped from in an
+ automated fashion. This is when entering the STALE state where all
+ DNSSEC validation starts to fail. If this happens it is concievable
+ that it is better to completely discard the stale trust anchors
+ (thereby reverting to the PRIMING state where validation is not
+ possible). A local policy that automates removal of stale trust
+ anchors is therefore suggested.
+
+
+3.5 Possible transactions
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 11]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+3.5.1 Single DNSKEY replaced
+
+
+ This is probably the most typical transaction on the zone owners
+ part. The result should be that if the threshold criterion is
+ satisfied then the key store is updated by removal of the old trust
+ anchor and addition of the new key as a new trust anchor. Note that
+ if the DNSKEY RRset contains exactly M keys replacement of keys is
+ not possible, i.e. for automatic rollover to work M must be stricly
+ less than N.
+
+
+3.5.2 Addition of a new DNSKEY (no removal)
+
+
+ If the threshold criterion is satisfied then the new key is added as
+ a configured trust anchor. Not more than N-M keys can be added at
+ once, since otherwise the algorithm will fail.
+
+
+3.5.3 Removal of old DNSKEY (no addition)
+
+
+ If the threshold criterion is satisfied then the old key is removed
+ from being a configured trust anchor. Note that it is not possible
+ to reduce the size of the DNSKEY RRset to a size smaller than the
+ minimum required value for M.
+
+
+3.5.4 Multiple DNSKEYs replaced
+
+
+ Arguably it is not a good idea for the zone administrator to replace
+ several keys at the same time, but from the resolver point of view
+ this is exactly what will happen if the validating resolver for some
+ reason failed to notice a previous rollover event.
+
+
+ Not more than N-M keys can be replaced at one time or the threshold
+ criterion will not be satisfied. Or, expressed another way: as long
+ as the number of changed keys is less than or equal to N-M the
+ validator is in state OUT-OF-SYNC. When the number of changed keys
+ becomes greater than N-M the state changes to UNSYNCABLE and manual
+ action is needed.
+
+
+3.6 Removal of trust anchors for a trust point
+
+
+ If the parent of a secure entry point gets signed and it's trusted
+ keys get configured in the key store of the validating resolver then
+ the configured trust anchors for the child should be removed entirely
+ unless explicitly configured (in the utility configuration) to be an
+ exception.
+
+
+ The reason for such a configuration would be that the resolver has a
+ local policy that requires maintenance of trusted keys further down
+ the tree hierarchy than strictly needed from the point of view.
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 12]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ The default action when the parent zone changes from unsigned to
+ signed should be to remove the configured trust anchors for the
+ child. This form of "garbage collect" will ensure that the automatic
+ rollover machinery scales as DNSSEC deployment progresses.
+
+
+3.7 No need for resolver-side overlap of old and new keys
+
+
+ It is worth pointing out that there is no need for the resolver to
+ keep state about old keys versus new keys, beyond the requirement of
+ tracking signature inception time for the covering RRSIGs as
+ described in Section 3.4.
+
+
+ From the resolver point of view there are only trusted and not
+ trusted keys. The reason is that the zone owner needs to do proper
+ maintenance of RRSIGs regardless of the resolver rollover mechanism
+ and hence must ensure that no key rolled out out the DNSKEY set until
+ there cannot be any RRSIGs created by this key still legally cached.
+
+
+ Hence the rollover mechanism is entirely stateless with regard to the
+ keys involved: as soon as the resolver (or in this case the rollover
+ tracking utility) detects a change in the DNSKEY RRset (i.e. it is
+ now in the state OUT-OF-SYNC) with a sufficient number of matching
+ RRSIGs the configured trust anchors are immediately updated (and
+ thereby the machine return to state IN-SYNC). I.e. the rollover
+ machine changes states (mostly oscillating between IN-SYNC and
+ OUT-OF-SYNC), but the status of the DNSSEC keys is stateless.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 13]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+4. Bootstrapping automatic rollovers
+
+
+ It is expected that with the ability to automatically roll trust
+ anchors at trust points will follow a diminished unwillingness to
+ roll these keys, since the risks associated with stale keys are
+ minimized.
+
+
+ The problem of "priming" the trust anchors, or bringing them into
+ sync (which could happen if a resolver is off line for a long period
+ in which a set of SEP keys in a zone 'evolve' away from its trust
+ anchor configuration) remains.
+
+
+ For (re)priming we can rely on out of band technology and we propose
+ the following framework.
+
+
+4.1 Priming Keys
+
+
+ If all the trust anchors roll somewhat frequently (on the order of
+ months or at most about a year) then it will not be possible to
+ design a device, or a software distribution that includes trust
+ anchors, that after being manufactured is put on a shelf for several
+ key rollover periods before being brought into use (since no trust
+ anchors that were known at the time of manufacture remain active).
+
+
+ To alleviate this we propose the concept of "priming keys". Priming
+ keys are ordinary DNSSEC Key Signing Keys with the characteristic
+ that
+ o The private part of a priming key signs the DNSKEY RRset at the
+ security apex, i.e. at least one RRSIG DNSKEY is created by a
+ priming key rather than by an "ordinary" trust anchor
+ o the public parts of priming keys are not included in the DNSKEY
+ RRset. Instead the public parts of priming keys are only
+ available out-of-band.
+ o The public parts of the priming keys have a validity period.
+ Within this period they can be used to obtain trust anchors.
+ o The priming key pairs are long lived (relative to the key rollover
+ period.)
+
+
+4.1.1 Bootstrapping trust anchors using a priming key
+
+
+ To install the trust anchors for a particular security apex an
+ administrator of a validating resolver will need to:
+ o query for the DNSKEY RRset of the zone at the security apex;
+ o verify the self signatures of all DNSKEYs in the RRset;
+ o verify the signature of the RRSIG made with a priming key --
+ verification using one of the public priming keys that is valid at
+ that moment is sufficient;
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 14]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ o create the trust anchors by extracting the DNSKEY RRs with the SEP
+ flag set.
+ The SEP keys with algorithms unknown to the validating resolver
+ SHOULD be ignored during the creation of the trust anchors.
+
+
+4.1.2 Distribution of priming keys
+
+
+ The public parts of the priming keys SHOULD be distributed
+ exclusively through out-of-DNS mechanisms. The requirements for a
+ distribution mechanism are:
+ o it can carry the "validity" period for the priming keys;
+ o it can carry the self-signature of the priming keys;
+ o and it allows for verification using trust relations outside the
+ DNS.
+ A distribution mechanism would benefit from:
+ o the availability of revocation lists;
+ o the ability of carrying zone owners policy information such as
+ recommended values for "M" and "N" and a rollover frequency;
+ o and the technology on which is based is readily available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 15]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+5. The Threshold Rollover Mechanism vs Priming
+
+
+ There is overlap between the threshold-based trust updater and the
+ Priming method. One could exclusively use the Priming method for
+ maintaining the trust anchors. However the priming method probably
+ relies on "non-DNS' technology and may therefore not be available for
+ all devices that have a resolver.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 16]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+6. Security Considerations
+
+
+6.1 Threshold-based Trust Update Security Considerations
+
+
+ A clear issue for resolvers will be how to ensure that they track all
+ rollover events for the zones they have configure trust anchors for.
+ Because of temporary outages validating resolvers may have missed a
+ rollover of a KSK. The parameters that determine the robustness
+ against failures are: the length of the period between rollovers
+ during which the KSK set is stable and validating resolvers can
+ actually notice the change; the number of available KSKs (i.e. N)
+ and the number of signatures that may fail to validate (i.e. N-M).
+
+
+ With a large N (i.e. many KSKs) and a small value of M this
+ operation becomes more robust since losing one key, for whatever
+ reason, will not be crucial. Unfortunately the choice for the number
+ of KSKs is a local policy issue for the zone owner while the choice
+ for the parameter M is a local policy issue for the resolver
+ administrator.
+
+
+ Higher values of M increase the resilience against attacks somewhat;
+ more signatures need to verify for a rollover to be approved. On the
+ other hand the number of rollover events that may pass unnoticed
+ before the resolver reaches the UNSYNCABLE state goes down.
+
+
+ The threshold-based trust update intentionally does not provide a
+ revocation mechanism. In the case that a sufficient number of
+ private keys of a zone owner are simultaneously compromised the the
+ attacker may use these private keys to roll the trust anchors of (a
+ subset of) the resolvers. This is obviously a bad situation but it
+ is not different from most other public keys systems.
+
+
+ However, it is important to point out that since any reasonable trust
+ anchor rollover policy (in validating resolvers) will require more
+ than one RRSIG to validate this proposal does provide security
+ concious zone administrators with the option of not storing the
+ individual private keys in the same location and thereby decreasing
+ the likelihood of simultaneous compromise.
+
+
+6.2 Priming Key Security Considerations
+
+
+ Since priming keys are not included in the DNSKEY RR set they are
+ less sensitive to packet size constraints and can be chosen
+ relatively large. The private parts are only needed to sign the
+ DNSKEY RR set during the validity period of the particular priming
+ key pair. Note that the private part of the priming key is used each
+ time when a DNSKEY RRset has to be resigned. In practice there is
+ therefore little difference between the usage pattern of the private
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 17]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ part of key signing keys and priming keys.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 18]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+7. IANA Considerations
+
+
+ NONE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 19]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+8. References
+
+
+8.1 Normative References
+
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+ [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+ (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+ RFC 3757, May 2004.
+
+
+ [3] Arends, R., "Resource Records for the DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-records-10 (work in progress),
+ September 2004.
+
+
+8.2 Informative References
+
+
+ [4] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
+ "DNS Security Introduction and Requirements",
+ draft-ietf-dnsext-dnssec-intro-12 (work in progress), September
+ 2004.
+
+
+ [5] Kolkman, O., "DNSSEC Operational Practices",
+ draft-ietf-dnsop-dnssec-operational-practices-01 (work in
+ progress), May 2004.
+
+
+ [6] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
+ Public Key Infrastructure Certificate and CRL Profile", RFC
+ 2459, January 1999.
+
+
+
+Authors' Addresses
+
+
+ Johan Ihren
+ Autonomica AB
+ Bellmansgatan 30
+ Stockholm SE-118 47
+ Sweden
+
+
+ EMail: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 20]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+ Olaf M. Kolkman
+ RIPE NCC
+ Singel 256
+ Amsterdam 1016 AB
+ NL
+
+
+ Phone: +31 20 535 4444
+ EMail: olaf@ripe.net
+ URI: http://www.ripe.net/
+
+
+
+ Bill Manning
+ EP.net
+ Marina del Rey, CA 90295
+ USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 21]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+Appendix A. Acknowledgments
+
+
+ The present design for in-band automatic rollovers of DNSSEC trust
+ anchors is the result of many conversations and it is no longer
+ possible to remember exactly who contributed what.
+
+
+ In addition we've also had appreciated help from (in no particular
+ order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
+ Larson and Mark Kosters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 22]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+Appendix B. Document History
+
+
+ This appendix will be removed if and when the document is submitted
+ to the RFC editor.
+
+
+ The version you are reading is tagged as $Revision: 1.1.230.1 $.
+
+
+ Text between square brackets, other than references, are editorial
+ comments and will be removed.
+
+
+B.1 prior to version 00
+
+
+ This draft was initially published as a personal submission under the
+ name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.
+
+
+ Kolkman documented the ideas provided by Ihren and Manning. In the
+ process of documenting (and prototyping) Kolkman changed some of the
+ details of the M-N algorithms working. Ihren did not have a chance
+ to review the draft before Kolkman posted;
+
+
+ Kolkman takes responsibilities for omissions, fuzzy definitions and
+ mistakes.
+
+
+B.2 version 00
+ o The name of the draft was changed as a result of the draft being
+ adopted as a working group document.
+ o A small section on the concept of stale trust anchors was added.
+ o The different possible states are more clearly defined, including
+ examples of transitions between states.
+ o The terminology is changed throughout the document. The old term
+ "M-N" is replaced by "threshold" (more or less). Also the
+ interpretation of the constants M and N is significantly
+ simplified to bring the usage more in line with "standard"
+ threshold terminlogy.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 23]
+Internet-Draft DNSSEC Threshold-based Trust Update October 2004
+
+
+
+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 (2004). 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.
+
+
+
+
+Ihren, et al. Expires April 18, 2005 [Page 24]
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt b/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
new file mode 100644
index 0000000..7cb9063
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
@@ -0,0 +1,730 @@
+
+
+
+
+Network Working Group M. StJohns
+Internet-Draft Nominum, Inc.
+Expires: July 14, 2006 January 10, 2006
+
+
+ Automated Updates of DNSSEC Trust Anchors
+ draft-ietf-dnsext-trustupdate-timers-02
+
+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 July 14, 2006.
+
+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 single key compromise of a key 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.
+
+ This mechanism, if adopted, will require changes to resolver
+ management behavior (but not resolver resolution behavior), and the
+
+
+
+StJohns Expires July 14, 2006 [Page 1]
+
+Internet-Draft trustanchor-update January 2006
+
+
+ addition of a single flag bit to the DNSKEY record.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
+ 1.2. Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
+ 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.3. Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
+ 2.4. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.5. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
+ 2.5.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
+ 2.5.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
+ 2.5.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6
+ 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
+ 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 4.3. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 8
+ 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.1. Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 9
+ 5.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
+ 5.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 9
+ 5.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 7.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
+ 7.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
+ 7.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
+ 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
+ Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ Intellectual Property and Copyright Statements . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+StJohns Expires July 14, 2006 [Page 2]
+
+Internet-Draft trustanchor-update January 2006
+
+
+1. Introduction
+
+ As part of the reality of fielding DNSSEC (Domain Name System
+ Security Extensions) [RFC2535] [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].
+
+1.2. Changes since -00
+
+ Added the concept of timer triggered resolver queries to refresh the
+
+
+
+StJohns Expires July 14, 2006 [Page 3]
+
+Internet-Draft trustanchor-update January 2006
+
+
+ resolvers view of the trust anchor key RRSet.
+
+ Re-submitted expired draft as -01. Updated DNSSEC RFC References.
+
+ Draft -02. Added the IANA Considerations section. Added text to
+ describe what happens if all trust anchors at a trust point are
+ deleted.
+
+
+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 new SEP key is added to a trust point
+ DNSKEY RRSet, and when that RRSet is validated by an existing trust
+ anchor, then the new key can be added to the set of trust anchors.
+
+ 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, an attacker could add a new key and revoke 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 6 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 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.
+
+ 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. [msj3]
+
+ In the given example, the attacker could revoke B because it has
+
+
+
+StJohns Expires July 14, 2006 [Page 4]
+
+Internet-Draft trustanchor-update January 2006
+
+
+ knowledge of B's private key, but could not revoke A.
+
+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 the 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 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. Remove Hold-down
+
+ A new key which has been seen by the resolver, but hasn't reached
+ it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
+
+
+
+StJohns Expires July 14, 2006 [Page 5]
+
+Internet-Draft trustanchor-update January 2006
+
+
+ zone owner. If the resolver sees a validated DNSKEY RRSet without
+ this key, it waits for the remove hold-down time and then, if the key
+ hasn't reappeared, SHOULD discard any information about the key.
+
+2.4. 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
+ RRSet or half the RRSIG expiration interval. 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.
+
+2.5. Resolver Parameters
+
+2.5.1. Add Hold-Down Time
+
+ The add hold-down time is 30 days or the expiration time of the TTL
+ of the first trust point DNSKEY RRSet which contained the 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.5.2. Remove Hold-Down Time
+
+ The remove hold-down time is 30 days.
+
+2.5.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
+ validing the revocation.
+
+
+
+
+
+StJohns Expires July 14, 2006 [Page 6]
+
+Internet-Draft trustanchor-update January 2006
+
+
+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
+ 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.
+
+ [msj1] 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 | | | | | | |
+ ----------------------------------------------------------
+
+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 its 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 July 14, 2006 [Page 7]
+
+Internet-Draft trustanchor-update January 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 hasn't yet been
+ seen at the resolver.
+ 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. [Discussion
+ item: Should a missing key be considered revoked after some period
+ of time?]
+ 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.
+
+4.3. 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 trust points, data at and below
+ the deleted trust point are considered insecure. If there there ARE
+ superior trust points, data at and below the deleted trust point are
+ evaluated with respect to the superior trust point.
+
+
+5. Scenarios
+
+ 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.
+
+
+
+
+StJohns Expires July 14, 2006 [Page 8]
+
+Internet-Draft trustanchor-update January 2006
+
+
+ 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.
+
+5.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.
+
+5.2. Deleting a Trust Anchor
+
+ Assume existing trust anchors 'A' and 'B' and that you want to revoke
+ and delete 'A'.
+ 1. Set the revolcation 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.
+
+5.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.
+
+5.4. Active Key Compromised
+
+ This is the same as the mechanism for Key Roll-Over (Section 5.3)
+ above assuming 'A' is the active key.
+
+
+
+StJohns Expires July 14, 2006 [Page 9]
+
+Internet-Draft trustanchor-update January 2006
+
+
+5.5. Stand-by Key Compromised
+
+ Using the same assumptions and naming conventions as Key Roll-Over
+ (Section 5.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. 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.
+
+
+7. Security Considerations
+
+7.1. Key Ownership vs Acceptance Policy
+
+ The reader should note that, while the zone owner is responsible
+ 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
+ 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.
+
+7.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.
+
+
+
+
+StJohns Expires July 14, 2006 [Page 10]
+
+Internet-Draft trustanchor-update January 2006
+
+
+7.3. Dynamic Updates
+
+ Allowing a resolver to update its trust anchor set based 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
+ lack of a standard management framework for DNS, this approach is no
+ worse than the existing situation.
+
+8. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [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
+
+ [msj1] msj: N.B. This table is preliminary and will be revised to
+ match implementation experience. For example, should there
+ be a state for "Add hold-down expired, but haven't seen the
+ new RRSet"?
+
+ [msj2] msj: To be assigned.
+
+ [msj3] msj: For discussion: What's the implementation guidance for
+ resolvers currently with respect to the non-assigned flag
+ bits? If they consider the flag bit when doing key matching
+ at the trust anchor, they won't be able to match.
+
+
+
+
+
+
+StJohns Expires July 14, 2006 [Page 11]
+
+Internet-Draft trustanchor-update January 2006
+
+
+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 July 14, 2006 [Page 12]
+
+Internet-Draft trustanchor-update January 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.
+
+
+
+
+StJohns Expires July 14, 2006 [Page 13]
+
+
diff --git a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
new file mode 100644
index 0000000..00476ae
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
@@ -0,0 +1,522 @@
+
+INTERNET-DRAFT Donald E. Eastlake 3rd
+UPDATES RFC 2845 Motorola Laboratories
+Expires: July 2006 January 2006
+
+ HMAC SHA TSIG Algorithm Identifiers
+ ---- --- ---- --------- -----------
+ <draft-ietf-dnsext-tsig-sha-06.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.
+
+ This draft is intended to be become a Proposed Standard RFC.
+ Distribution of this document is unlimited. Comments should be sent
+ to the DNSEXT 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
+
+ Use of the Domain Name System TSIG resource record requires
+ specification of a cryptographic message authentication code.
+ Currently identifiers have been specified only for the HMAC MD5
+ (Message Digest) and GSS (Generic Security Service) TSIG algorithms.
+ This document standardizes identifiers and implementation
+ requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
+ algorithms and standardizes how to specify and handle the truncation
+ of HMAC values in TSIG.
+
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+
+
+D. Eastlake 3rd [Page 1]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+Table of Contents
+
+ Status of This Document....................................1
+ Abstract...................................................1
+ Copyright Notice...........................................1
+
+ Table of Contents..........................................2
+
+ 1. Introduction............................................3
+
+ 2. Algorithms and Identifiers..............................4
+
+ 3. Specifying Truncation...................................5
+ 3.1 Truncation Specification...............................5
+
+ 4. TSIG Truncation Policy and Error Provisions.............6
+
+ 5. IANA Considerations.....................................7
+ 6. Security Considerations.................................7
+ 7. Copyright and Disclaimer................................7
+
+ 8. Normative References....................................8
+ 9. Informative References..................................8
+
+ Author's Address...........................................9
+ Additional IPR Provisions..................................9
+ Expiration and File Name...................................9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 2]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+1. Introduction
+
+ [RFC 2845] specifies a TSIG Resource Record (RR) that can be used to
+ authenticate DNS (Domain Name System [STD 13]) queries and responses.
+ This RR contains a domain name syntax data item which names the
+ authentication algorithm used. [RFC 2845] defines the HMAC-MD5.SIG-
+ ALG.REG.INT name for authentication codes using the HMAC [RFC 2104]
+ algorithm with the MD5 [RFC 1321] hash algorithm. IANA has also
+ registered "gss-tsig" as an identifier for TSIG authentication where
+ the cryptographic operations are delegated to the Generic Security
+ Service (GSS) [RFC 3645].
+
+ It should be noted that use of TSIG presumes prior agreement, between
+ the resolver and server involved, as to the algorithm and key to be
+ used.
+
+ In Section 2, this document specifies additional names for TSIG
+ authentication algorithms based on US NIST SHA (United States,
+ National Institute of Science and Technology, Secure Hash Algorithm)
+ algorithms and HMAC and specifies the implementation requirements for
+ those algorithms.
+
+ In Section 3, this document specifies the effect of inequality
+ between the normal output size of the specified hash function and the
+ length of MAC (message authentication code) data given in the TSIG
+ RR. In particular, it specifies that a shorter length field value
+ specifies truncation and a longer length field is an error.
+
+ In Section 4, policy restrictions and implications related to
+ truncation and a new error code to indicate truncation shorter than
+ permitted by policy are described and specified.
+
+ The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
+ defined in [RFC 2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 3]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+2. Algorithms and Identifiers
+
+ TSIG Resource Records (RRs) [RFC 2845] are used to authenticate DNS
+ queries and responses. They are intended to be efficient symmetric
+ authentication codes based on a shared secret. (Asymmetric signatures
+ can be provided using the SIG RR [RFC 2931]. In particular, SIG(0)
+ can be used for transaction signatures.) Used with a strong hash
+ function, HMAC [RFC 2104] provides a way to calculate such symmetric
+ authentication codes. The only specified HMAC based TSIG algorithm
+ identifier has been HMAC-MD5.SIG-ALG.REG.INT based on MD5 [RFC 1321].
+
+ The use of SHA-1 [FIPS 180-2, RFC 3174], which is a 160 bit hash, as
+ compared with the 128 bits for MD5, and additional hash algorithms in
+ the SHA family [FIPS 180-2, RFC 3874, SHA2draft] with 224, 256, 384,
+ and 512 bits, may be preferred in some cases particularly since
+ increasingly successful cryptanalytic attacks are being made on the
+ shorter hashes.
+
+ Use of TSIG between a DNS resolver and server is by mutual agreement.
+ That agreement can include the support of additional algorithms and
+ criteria as to which algorithms and truncations are acceptable,
+ subject to the restriction and guidelines in Section 3 and 4 below.
+ Key agreement can be by the TKEY mechanism [RFC 2930] or other
+ mutually agreeable method.
+
+ The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
+ included in the table below for convenience. Implementations which
+ support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
+ implement gss-tsig and the other algorithms listed below.
+
+ Mandatory HMAC-MD5.SIG-ALG.REG.INT
+ Optional gss-tsig
+ Mandatory hmac-sha1
+ Optional hmac-sha224
+ Mandatory hmac-sha256
+ Optional hamc-sha384
+ Optional hmac-sha512
+
+ SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 4]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+3. Specifying Truncation
+
+ When space is at a premium and the strength of the full length of an
+ HMAC is not needed, it is reasonable to truncate the HMAC output and
+ use the truncated value for authentication. HMAC SHA-1 truncated to
+ 96 bits is an option available in several IETF protocols including
+ IPSEC and TLS.
+
+ The TSIG RR [RFC 2845] includes a "MAC size" field, which gives the
+ size of the MAC field in octets. But [RFC 2845] does not specify what
+ to do if this MAC size differs from the length of the output of HMAC
+ for a particular hash function. Truncation is indicated by a MAC size
+ less than the HMAC size as specified below.
+
+
+
+3.1 Truncation Specification
+
+ The specification for TSIG handling is changed as follows:
+
+ 1. If "MAC size" field is greater than HMAC output length:
+ This case MUST NOT be generated and if received MUST cause the
+ packet to be dropped and RCODE 1 (FORMERR) to be returned.
+
+ 2. If "MAC size" field equals HMAC output length:
+ Operation is as described in [RFC 2845] with the entire output
+ HMAC output present.
+
+ 3. "MAC size" field is less than HMAC output length but greater than
+ that specified in case 4 below:
+ This is sent when the signer has truncated the HMAC output to
+ an allowable length, as described in RFC 2104, taking initial
+ octets and discarding trailing octets. TSIG truncation can only be
+ to an integral number of octets. On receipt of a packet with
+ truncation thus indicated, the locally calculated MAC is similarly
+ truncated and only the truncated values compared for
+ authentication. The request MAC used when calculating the TSIG MAC
+ for a reply is the truncated request MAC.
+
+ 4. "MAC size" field is less than the larger of 10 (octets) and half
+ the length of the hash function in use:
+ With the exception of certain TSIG error messages described in
+ RFC 2845 section 3.2 where it is permitted that the MAC size be
+ zero, this case MUST NOT be generated and if received MUST cause
+ the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
+ size limit for this case can also, for the hash functions
+ mentioned in this document, be stated as less than half the hash
+ function length for hash functions other than MD5 and less than 10
+ octets for MD5.
+
+
+
+D. Eastlake 3rd [Page 5]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+4. TSIG Truncation Policy and Error Provisions
+
+ Use of TSIG is by mutual agreement between a resolver and server.
+ Implicit in such "agreement" are criterion as to acceptable keys and
+ algorithms and, with the extensions in this document, truncations.
+ Note that it is common for implementations to bind the TSIG secret
+ key or keys that may be in place at a resolver and server to
+ particular algorithms. Thus such implementations only permit the use
+ of an algorithm if there is an associated key in place. Receipt of an
+ unknown, unimplemented, or disabled algorithm typically results in a
+ BADKEY error.
+
+ Local policies MAY require the rejection of TSIGs even though they
+ use an algorithm for which implementation is mandatory.
+
+ When a local policy permits acceptance of a TSIG with a particular
+ algorithm and a particular non-zero amount of truncation it SHOULD
+ also permit the use of that algorithm with lesser truncation (a
+ longer MAC) up to the full HMAC output.
+
+ Regardless of a lower acceptable truncated MAC length specified by
+ local policy, a reply SHOULD be sent with a MAC at least as long as
+ that in the corresponding request unless the request specified a MAC
+ length longer than the HMAC output.
+
+ Implementations permitting multiple acceptable algorithms and/or
+ truncations SHOULD permit this list to be ordered by presumed
+ strength and SHOULD allow different truncations for the same
+ algorithm to be treated as separate entities in this list. When so
+ implemented, policies SHOULD accept a presumed stronger algorithm and
+ truncation than the minimum strength required by the policy.
+
+ If a TSIG is received with truncation which is permitted under
+ Section 3 above but the MAC is too short for the local policy in
+ force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 6]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+5. IANA Considerations
+
+ This document, on approval for publication as a standards track RFC,
+ (1) registers the new TSIG algorithm identifiers listed in Section 2
+ with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
+ Section 4. [RFC 2845]
+
+
+
+6. Security Considerations
+
+ For all of the message authentication code algorithms listed herein,
+ those producing longer values are believed to be stronger; however,
+ while there have been some arguments that mild truncation can
+ strengthen a MAC by reducing the information available to an
+ attacker, excessive truncation clearly weakens authentication by
+ reducing the number of bits an attacker has to try to break the
+ authentication by brute force [RFC 2104].
+
+ Significant progress has been made recently in cryptanalysis of hash
+ function of the type used herein, all of which ultimately derive from
+ the design of MD4. While the results so far should not effect HMAC,
+ the stronger SHA-1 and SHA-256 algorithms are being made mandatory
+ due to caution.
+
+ See the Security Considerations section of [RFC 2845]. See also the
+ Security Considerations section of [RFC 2104] from which the limits
+ on truncation in this RFC were taken.
+
+
+
+7. Copyright and Disclaimer
+
+ 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.
+
+
+
+
+
+D. Eastlake 3rd [Page 7]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+8. Normative References
+
+ [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
+ Federal Information Processing Standard, with Change Notice 1,
+ February 2004.
+
+ [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
+ 1321, April 1992.
+
+ [RFC 2104] - Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104, February 1997.
+
+ [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+ Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
+ RFC 2845, May 2000.
+
+ [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
+ 1 (SHA1)", RFC 3174, September 2001.
+
+ [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
+ September 2004,
+
+ [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
+ (SHA)", draft-eastlake-sha2-*.txt, work in progress.
+
+ [STD 13]
+ Mockapetris, P., "Domain names - concepts and facilities", STD
+ 13, RFC 1034, November 1987.
+
+ Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+
+
+9. Informative References.
+
+ [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
+ (TKEY RR)", RFC 2930, September 2000.
+
+ [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
+ Signatures ( SIG(0)s )", RFC 2931, September 2000.
+
+ [RFC 3645] - 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.
+
+
+
+D. Eastlake 3rd [Page 8]
+
+
+INTERNET-DRAFT HMAC-SHA TSIG Identifiers
+
+
+Author's Address
+
+ Donald E. Eastlake 3rd
+ Motorola Laboratories
+ 155 Beaver Street
+ Milford, MA 01757 USA
+
+ Telephone: +1-508-786-7554 (w)
+
+ EMail: Donald.Eastlake@motorola.com
+
+
+
+Additional IPR Provisions
+
+ 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.
+
+
+
+Expiration and File Name
+
+ This draft expires in July 2006.
+
+ Its file name is draft-ietf-dnsext-tsig-sha-06.txt
+
+
+
+
+
+
+
+
+D. Eastlake 3rd [Page 9]
+
diff --git a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
new file mode 100644
index 0000000..9cf88a5
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
@@ -0,0 +1,1063 @@
+Internet-Draft dnsext-wcard January 9, 2006
+
+DNSEXT Working Group E. Lewis
+INTERNET DRAFT NeuStar
+Expiration Date: July 9, 2006 January 9, 2006
+Updates RFC 1034, RFC 2672
+
+ The Role of Wildcards
+ in the Domain Name System
+ draft-ietf-dnsext-wcard-clarify-10.txt
+
+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 July 9, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This is an update to the wildcard definition of RFC 1034. The
+ interaction with wildcards and CNAME is changed, an error
+ condition removed, and the words defining some concepts central
+ to wildcards are changed. The overall goal is not to change
+ wildcards, but to refine the definition of RFC 1034.
+
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 1]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+Table of Contents
+
+1. Introduction . . . . . . . . . . . . . . . . 3
+1 1 Motivation 3
+1 2 The Original Definition 3
+1 3 Roadmap to This Document 4
+1 3 1 New Terms 4
+1.3.2 Changed Text 5
+1.3.3 Considerations with Special Types 5
+1.4 Standards Terminology 5
+2. Wildcard Syntax . . . . . . . . . . . . . . . 6
+2.1 Identifying a Wildcard 6
+2.1.1 Wild Card Domain Name and Asterisk Label 6
+2.1.2 Asterisks and Other Characters 6
+2.1.3 Non-terminal Wild Card Domain Names 6
+2.2 Existence Rules 7
+2.2.1 An Example 7
+2.2.2 Empty Non-terminals 9
+2.2.3 Yet Another Definition of Existence 10
+2.3 When is a Wild Card Domain Name Not Special 10
+3. Impact of a Wild Card Domain Name On a Response . . . . . 10
+3.1 Step 2 10
+3.2 Step 3 11
+3.3 Part 'c' 11
+3.3.1 Closest Encloser and the Source of Synthesis 12
+3.3.2 Closest Encloser and Source of Synthesis Examples 12
+3.3.3 Type Matching 13
+4. Considerations with Special Types . . . . . . . . . 13
+4.1 SOA RRSet at a Wild Card Domain Name 13
+4.2 NS RRSet at a Wild Card Domain Name 14
+4.2.1 Discarded Notions 14
+4.3 CNAME RRSet at a Wild Card Domain Name 15
+4.4 DNAME RRSet at a Wild Card Domain Name 15
+4.5 SRV RRSet at a Wild Card Domain Name 16
+4.6 DS RRSet at a Wild Card Domain Name 16
+4.7 NSEC RRSet at a Wild Card Domain Name 17
+4.8 RRSIG at a Wild Card Domain Name 17
+4.9 Empty Non-terminal Wild Card Domain Name 17
+5. Security Considerations . . . . . . . . . . . . . 17
+6. IANA Considerations . . . . . . . . . . . . . 17
+7. References . . . . . . . . . . . . . 17
+8. Editor . . . . . . . . . . . . . 18
+9. Others Contributing to the Document . . . . . . . . 18
+10. Trailing Boilerplate . . . . . . . . . . . . . 19
+
+
+
+
+
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 2]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+1. Introduction
+
+ In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
+ synthesis of answers from special resource records called
+ wildcards. The definition in RFC 1034 is incomplete and has
+ proven to be confusing. This document describes the wildcard
+ synthesis by adding to the discussion and making limited
+ modifications. Modifications are made to close inconsistencies
+ that have led to interoperability issues. This description
+ does not expand the service intended by the original definition.
+
+ Staying within the spirit and style of the original documents,
+ this document avoids specifying rules for DNS implementations
+ regarding wildcards. The intention is to only describe what is
+ needed for interoperability, not restrict implementation choices.
+ In addition, consideration is given to minimize any backwards
+ compatibility issues with implementations that comply with RFC
+ 1034's definition.
+
+ This document is focused on the concept of wildcards as defined
+ in RFC 1034. Nothing is implied regarding alternative means of
+ synthesizing resource record sets, nor are alternatives discussed.
+
+1.1 Motivation
+
+ Many DNS implementations diverge, in different ways, from the
+ original definition of wildcards. Although there is clearly a
+ need to clarify the original documents in light of this alone,
+ the impetus for this document lay in the engineering of the DNS
+ security extensions [RFC4033]. With an unclear definition of
+ wildcards the design of authenticated denial became entangled.
+
+ This document is intended to limit its changes, documenting only
+ those based on implementation experience, and to remain as close
+ to the original document as possible. To reinforce that this
+ document is meant to clarify and adjust and not redefine wildcards,
+ relevant sections of RFC 1034 are repeated verbatim to facilitate
+ comparison of the old and new text.
+
+1.2 The Original Definition
+
+ The definition of the wildcard concept is comprised by the
+ documentation of the algorithm by which a name server prepares
+ a response (in RFC 1034's section 4.3.2) and the way in which
+ a resource record (set) is identified as being a source of
+ synthetic data (section 4.3.3).
+
+ This is the definition of the term "wildcard" as it appears in
+ RFC 1034, section 4.3.3.
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 3]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+# In the previous algorithm, special treatment was given to RRs with
+# owner names starting with the label "*". Such RRs are called
+# wildcards. Wildcard RRs can be thought of as instructions for
+# synthesizing RRs. When the appropriate conditions are met, the name
+# server creates RRs with an owner name equal to the query name and
+# contents taken from the wildcard RRs.
+
+ This passage follows the algorithm in which the term wildcard
+ is first used. In this definition, wildcard refers to resource
+ records. In other usage, wildcard has referred to domain names,
+ and it has been used to describe the operational practice of
+ relying on wildcards to generate answers. It is clear from this
+ that there is a need to define clear and unambiguous terminology
+ in the process of discussing wildcards.
+
+ The mention of the use of wildcards in the preparation of a
+ response is contained in step 3c of RFC 1034's section 4.3.2
+ entitled "Algorithm." Note that "wildcard" does not appear in
+ the algorithm, instead references are made to the "*" label.
+ The portion of the algorithm relating to wildcards is
+ deconstructed in detail in section 3 of this document, this is
+ the beginning of the relevant portion of the "Algorithm."
+
+# c. If at some label, a match is impossible (i.e., the
+# corresponding label does not exist), look to see if [...]
+# the "*" label exists.
+
+ The scope of this document is the RFC 1034 definition of
+ wildcards and the implications of updates to those documents,
+ such as DNSSEC. Alternate schemes for synthesizing answers are
+ not considered. (Note that there is no reference listed. No
+ document is known to describe any alternate schemes, although
+ there has been some mention of them in mailing lists.)
+
+1.3 Roadmap to This Document
+
+ This document accomplishes these three items.
+ o Defines new terms
+ o Makes minor changes to avoid conflicting concepts
+ o Describes the actions of certain resource records as wildcards
+
+1.3.1 New Terms
+
+ To help in discussing what resource records are wildcards, two
+ terms will be defined - "asterisk label" and "wild card domain
+ name". These are defined in section 2.1.1.
+
+ To assist in clarifying the role of wildcards in the name server
+ algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
+ encloser" are defined. These definitions are in section 3.3.2.
+ "Label match" is defined in section 3.2.
+
+DNSEXT Working Group Expires July 9, 2006 [Page 4]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ The new terms are used to make discussions of wildcards clearer.
+ Terminology doesn't directly have an impact on implementations.
+
+1.3.2 Changed Text
+
+ The definition of "existence" is changed superficially. This
+ change will not be apparent to implementations; it is needed to
+ make descriptions more precise. The change appears in section
+ 2.2.3.
+
+ RFC 1034, section 4.3.3., seems to prohibit having two asterisk
+ labels in a wildcard owner name. With this document the
+ restriction is removed entirely. This change and its implications
+ are in section 2.1.3.
+
+ The actions when a source of synthesis owns a CNAME RR are
+ changed to mirror the actions if an exact match name owns a
+ CNAME RR. This is an addition to the words in RFC 1034,
+ section 4.3.2, step 3, part c. The discussion of this is in
+ section 3.3.3.
+
+ Only the latter change represents an impact to implementations.
+ The definition of existence is not a protocol impact. The change
+ to the restriction on names is unlikely to have an impact, as
+ RFC 1034 contained no specification on when and how to enforce the
+ restriction.
+
+1.3.3 Considerations with Special Types
+
+ This document describes semantics of wildcard RRSets for
+ "interesting" types as well as empty non-terminal wildcards.
+ Understanding these situations in the context of wildcards has
+ been clouded because these types incur special processing if
+ they are the result of an exact match. This discussion is in
+ section 4.
+
+ These discussions do not have an implementation impact, they cover
+ existing knowledge of the types, but to a greater level of detail.
+
+1.4 Standards Terminology
+
+ This document does not use terms as defined in "Key words for use
+ in RFCs to Indicate Requirement Levels." [RFC2119]
+
+ Quotations of RFC 1034 are denoted by a '#' in the leftmost
+ column. References to section "4.3.2" are assumed to refer
+ to RFC 1034's section 4.3.2, simply titled "Algorithm."
+
+
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 5]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+2. Wildcard Syntax
+
+ The syntax of a wildcard is the same as any other DNS resource
+ record, across all classes and types. The only significant
+ feature is the owner name.
+
+ Because wildcards are encoded as resource records with special
+ names, they are included in zone transfers and incremental zone
+ transfers[RFC1995] just as non-wildcard resource records are.
+ This feature has been under appreciated until discussions on
+ alternative approaches to wildcards appeared on mailing lists.
+
+2.1 Identifying a Wildcard
+
+ To provide a more accurate description of wildcards, the
+ definition has to start with a discussion of the domain names
+ that appear as owners. Two new terms are needed, "Asterisk
+ Label" and "Wild Card Domain Name."
+
+2.1.1 Wild Card Domain Name and Asterisk Label
+
+ A "wild card domain name" is defined by having its initial
+ (i.e., left-most or least significant) label be, in binary format:
+
+ 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
+
+ The first octet is the normal label type and length for a 1 octet
+ long label, the second octet is the ASCII representation [RFC20]
+ for the '*' character.
+
+ A descriptive name of a label equaling that value is an "asterisk
+ label."
+
+ RFC 1034's definition of wildcard would be "a resource record
+ owned by a wild card domain name."
+
+2.1.2 Asterisks and Other Characters
+
+ No label values other than that in section 2.1.1 are asterisk
+ labels, hence names beginning with other labels are never wild
+ card domain names. Labels such as 'the*' and '**' are not
+ asterisk labels so these labels do not start wild card domain
+ names.
+
+2.1.3 Non-terminal Wild Card Domain Names
+
+ In section 4.3.3, the following is stated:
+
+# .......................... The owner name of the wildcard RRs is of
+# the form "*.<anydomain>", where <anydomain> is any domain name.
+# <anydomain> should not contain other * labels......................
+
+DNSEXT Working Group Expires July 9, 2006 [Page 6]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ The restriction is now removed. The original documentation of it
+ is incomplete and the restriction does not serve any purpose
+ given years of operational experience.
+
+ There are three possible reasons for putting the restriction in
+ place, but none of the three has held up over time. One is
+ that the restriction meant that there would never be subdomains
+ of wild card domain names, but the restriciton as stated still
+ permits "example.*.example." for instance. Another is that
+ wild card domain names are not intended to be empty non-terminals,
+ but this situation does not disrupt the algorithm in 4.3.2.
+ Finally, "nested" wild card domain names are not ambiguous once
+ the concept of the closest encloser had been documented.
+
+ A wild card domain name can have subdomains. There is no need
+ to inspect the subdomains to see if there is another asterisk
+ label in any subdomain.
+
+ A wild card domain name can be an empty non-terminal. (See the
+ upcoming sections on empty non-terminals.) In this case, any
+ lookup encountering it will terminate as would any empty
+ non-terminal match.
+
+2.2 Existence Rules
+
+ The notion that a domain name 'exists' is mentioned in the
+ definition of wildcards. In section 4.3.3 of RFC 1034:
+
+# Wildcard RRs do not apply:
+#
+...
+# - When the query name or a name between the wildcard domain and
+# the query name is know[n] to exist. For example, if a wildcard
+
+ "Existence" is therefore an important concept in the understanding
+ of wildcards. Unfortunately, the definition of what exists, in RFC
+ 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is
+ taken at the definition of existence.
+
+2.2.1 An Example
+
+ To illustrate what is meant by existence consider this complete
+ zone:
+
+
+
+
+
+
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 7]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ $ORIGIN example.
+ example. 3600 IN SOA <SOA RDATA>
+ example. 3600 NS ns.example.com.
+ example. 3600 NS ns.example.net.
+ *.example. 3600 TXT "this is a wild card"
+ *.example. 3600 MX 10 host1.example.
+ sub.*.example. 3600 TXT "this is not a wild card"
+ host1.example. 3600 A 192.0.4.1
+ _ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
+ _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
+ subdel.example. 3600 NS ns.example.com.
+ subdel.example. 3600 NS ns.example.net.
+
+ A look at the domain names in a tree structure is helpful:
+
+ |
+ -------------example------------
+ / / \ \
+ / / \ \
+ / / \ \
+ * host1 host2 subdel
+ | | |
+ | | |
+ sub _tcp _tcp
+ | |
+ | |
+ _ssh _ssh
+
+ The following responses would be synthesized from one of the
+ wildcards in the zone:
+
+ QNAME=host3.example. QTYPE=MX, QCLASS=IN
+ the answer will be a "host3.example. IN MX ..."
+
+ QNAME=host3.example. QTYPE=A, QCLASS=IN
+ the answer will reflect "no error, but no data"
+ because there is no A RR set at '*.example.'
+
+ QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
+ the answer will be "foo.bar.example. IN TXT ..."
+ because bar.example. does not exist, but the wildcard
+ does.
+
+ The following responses would not be synthesized from any of the
+ wildcards in the zone:
+
+ QNAME=host1.example., QTYPE=MX, QCLASS=IN
+ because host1.example. exists
+
+ QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
+ because sub.*.example. exists
+
+DNSEXT Working Group Expires July 9, 2006 [Page 8]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
+ because _tcp.host1.example. exists (without data)
+
+ QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
+ because subdel.example. exists (and is a zone cut)
+
+ QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
+ because *.example. exists
+
+ The final example highlights one common misconception about
+ wildcards. A wildcard "blocks itself" in the sense that a
+ wildcard does not match its own subdomains. I.e. "*.example."
+ does not match all names in the "example." zone, it fails to
+ match the names below "*.example." To cover names under
+ "*.example.", another wild card domain name is needed -
+ "*.*.example." - which covers all but it's own subdomains.
+
+2.2.2 Empty Non-terminals
+
+ Empty non-terminals [RFC2136, Section 7.16] are domain names
+ that own no resource records but have subdomains that do. In
+ section 2.2.1, "_tcp.host1.example." is an example of a empty
+ non-terminal name. Empty non-terminals are introduced by this
+ text in section 3.1 of RFC 1034:
+
+# The domain name space is a tree structure. Each node and leaf on
+# the tree corresponds to a resource set (which may be empty). The
+# domain system makes no distinctions between the uses of the
+# interior nodes and leaves, and this memo uses the term "node" to
+# refer to both.
+
+ The parenthesized "which may be empty" specifies that empty non-
+ terminals are explicitly recognized, and that empty non-terminals
+ "exist."
+
+ Pedantically reading the above paragraph can lead to an
+ interpretation that all possible domains exist - up to the
+ suggested limit of 255 octets for a domain name [RFC1035].
+ For example, www.example. may have an A RR, and as far as is
+ practically concerned, is a leaf of the domain tree. But the
+ definition can be taken to mean that sub.www.example. also
+ exists, albeit with no data. By extension, all possible domains
+ exist, from the root on down.
+
+ As RFC 1034 also defines "an authoritative name error indicating
+ that the name does not exist" in section 4.3.1, so this apparently
+ is not the intent of the original definition, justifying the
+ need for an updated definition in the next section.
+
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 9]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+2.2.3 Yet Another Definition of Existence
+
+ RFC1034's wording is fixed by the following paragraph:
+
+ The domain name space is a tree structure. Nodes in the tree
+ either own at least one RRSet and/or have descendants that
+ collectively own at least one RRSet. A node may exist with no
+ RRSets only if it has descendents that do, this node is an empty
+ non-terminal.
+
+ A node with no descendants is a leaf node. Empty leaf nodes do
+ not exist.
+
+ Note that at a zone boundary, the domain name owns data,
+ including the NS RR set. In the delegating zone, the NS RR
+ set is not authoritative, but that is of no consequence here.
+ The domain name owns data, therefore, it exists.
+
+2.3 When is a Wild Card Domain Name Not Special
+
+ When a wild card domain name appears in a message's query section,
+ no special processing occurs. An asterisk label in a query name
+ only matches a single, corresponding asterisk label in the
+ existing zone tree when the 4.3.2 algorithm is being followed.
+
+ When a wild card domain name appears in the resource data of a
+ record, no special processing occurs. An asterisk label in that
+ context literally means just an asterisk.
+
+3. Impact of a Wild Card Domain Name On a Response
+
+ RFC 1034's description of how wildcards impact response
+ generation is in its section 4.3.2. That passage contains the
+ algorithm followed by a server in constructing a response.
+ Within that algorithm, step 3, part 'c' defines the behavior of
+ the wildcard.
+
+ The algorithm in section 4.3.2. is not intended to be pseudo-code,
+ i.e., its steps are not intended to be followed in strict order.
+ The "algorithm" is a suggested means of implementing the
+ requirements. As such, in step 3, parts a, b, and c, do not have
+ to be implemented in that order, provided that the result of the
+ implemented code is compliant with the protocol's specification.
+
+3.1 Step 2
+
+ Step 2 of section 4.3.2 reads:
+
+# 2. Search the available zones for the zone which is the nearest
+# ancestor to QNAME. If such a zone is found, go to step 3,
+# otherwise step 4.
+
+DNSEXT Working Group Expires July 9, 2006 [Page 10]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ In this step, the most appropriate zone for the response is
+ chosen. The significance of this step is that it means all of
+ step 3 is being performed within one zone. This has significance
+ when considering whether or not an SOA RR can be ever be used for
+ synthesis.
+
+3.2 Step 3
+
+ Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
+ But the beginning of the step is important and needs explanation.
+
+# 3. Start matching down, label by label, in the zone. The
+# matching process can terminate several ways:
+
+ The word 'matching' refers to label matching. The concept
+ is based in the view of the zone as the tree of existing names.
+ The query name is considered to be an ordered sequence of
+ labels - as if the name were a path from the root to the owner
+ of the desired data. (Which it is - 3rd paragraph of RFC 1034,
+ section 3.1.)
+
+ The process of label matching a query name ends in exactly one of
+ three choices, the parts 'a', 'b', and 'c'. Either the name is
+ found, the name is below a cut point, or the name is not found.
+
+ Once one of the parts is chosen, the other parts are not
+ considered. (E.g., do not execute part 'c' and then change
+ the execution path to finish in part 'b'.) The process of label
+ matching is also done independent of the query type (QTYPE).
+
+ Parts 'a' and 'b' are not an issue for this clarification as they
+ do not relate to record synthesis. Part 'a' is an exact match
+ that results in an answer, part 'b' is a referral.
+
+3.3 Part 'c'
+
+ The context of part 'c' is that the process of label matching the
+ labels of the query name has resulted in a situation in which
+ there is no corresponding label in the tree. It is as if the
+ lookup has "fallen off the tree."
+
+# c. If at some label, a match is impossible (i.e., the
+# corresponding label does not exist), look to see if [...]
+# the "*" label exists.
+
+ To help describe the process of looking 'to see if [...] the "*"
+ label exists' a term has been coined to describe the last domain
+ (node) matched. The term is "closest encloser."
+
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 11]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+3.3.1 Closest Encloser and the Source of Synthesis
+
+ The closest encloser is the node in the zone's tree of existing
+ domain names that has the most labels matching the query name
+ (consecutively, counting from the root label downward). Each match
+ is a "label match" and the order of the labels is the same.
+
+ The closest encloser is, by definition, an existing name in the
+ zone. The closest encloser might be an empty non-terminal or even
+ be a wild card domain name itself. In no circumstances is the
+ closest encloser to be used to synthesize records for the current
+ query.
+
+ The source of synthesis is defined in the context of a query
+ process as that wild card domain name immediately descending
+ from the closest encloser, provided that this wild card domain
+ name exists. "Immediately descending" means that the source
+ of synthesis has a name of the form:
+ <asterisk label>.<closest encloser>.
+ A source of synthesis does not guarantee having a RRSet to use
+ for synthesis. The source of synthesis could be an empty
+ non-terminal.
+
+ If the source of synthesis does not exist (not on the domain
+ tree), there will be no wildcard synthesis. There is no search
+ for an alternate.
+
+ The important concept is that for any given lookup process, there
+ is at most one place at which wildcard synthetic records can be
+ obtained. If the source of synthesis does not exist, the lookup
+ terminates, the lookup does not look for other wildcard records.
+
+3.3.2 Closest Encloser and Source of Synthesis Examples
+
+ To illustrate, using the example zone in section 2.2.1 of this
+ document, the following chart shows QNAMEs and the closest
+ enclosers.
+
+ QNAME Closest Encloser Source of Synthesis
+ host3.example. example. *.example.
+ _telnet._tcp.host1.example. _tcp.host1.example. no source
+ _telnet._tcp.host2.example. host2.example. no source
+ _telnet._tcp.host3.example. example. *.example.
+ _chat._udp.host3.example. example. *.example.
+ foobar.*.example. *.example. no source
+
+
+
+
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 12]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+3.3.3 Type Matching
+
+ RFC 1034 concludes part 'c' with this:
+
+# If the "*" label does not exist, check whether the name
+# we are looking for is the original QNAME in the query
+# or a name we have followed due to a CNAME. If the name
+# is original, set an authoritative name error in the
+# response and exit. Otherwise just exit.
+#
+# If the "*" label does exist, match RRs at that node
+# against QTYPE. If any match, copy them into the answer
+# section, but set the owner of the RR to be QNAME, and
+# not the node with the "*" label. Go to step 6.
+
+ The final paragraph covers the role of the QTYPE in the lookup
+ process.
+
+ Based on implementation feedback and similarities between step
+ 'a' and step 'c' a change to this passage has been made.
+
+ The change is to add the following text to step 'c' prior to the
+ instructions to "go to step 6":
+
+ If the data at the source of synthesis is a CNAME, and
+ QTYPE doesn't match CNAME, copy the CNAME RR into the
+ answer section of the response changing the owner name
+ to the QNAME, change QNAME to the canonical name in the
+ CNAME RR, and go back to step 1.
+
+ This is essentially the same text in step a covering the
+ processing of CNAME RRSets.
+
+4. Considerations with Special Types
+
+ Sections 2 and 3 of this document discuss wildcard synthesis
+ with respect to names in the domain tree and ignore the impact
+ of types. In this section, the implication of wildcards of
+ specific types are discussed. The types covered are those
+ that have proven to be the most difficult to understand. The
+ types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
+ "none," i.e., empty non-terminal wild card domain names.
+
+4.1 SOA RRSet at a Wild Card Domain Name
+
+ A wild card domain name owning an SOA RRSet means that the
+ domain is at the root of the zone (apex). The domain can not
+ be a source of synthesis because that is, by definition, a
+ descendent node (of the closest encloser) and a zone apex is
+ at the top of the zone.
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 13]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ Although a wild card domain name owning an SOA RRSet can never
+ be a source of synthesis, there is no reason to forbid the
+ ownership of an SOA RRSet.
+
+ E.g., given this zone:
+ $ORIGIN *.example.
+ @ 3600 IN SOA <SOA RDATA>
+ 3600 NS ns1.example.com.
+ 3600 NS ns1.example.net.
+ www 3600 TXT "the www txt record"
+
+ A query for www.*.example.'s TXT record would still find the
+ "the www txt record" answer. The asterisk label only becomes
+ significant when section 4.3.2, step 3 part 'c' is in effect.
+
+ Of course, there would need to be a delegation in the parent
+ zone, "example." for this to work too. This is covered in the
+ next section.
+
+4.2 NS RRSet at a Wild Card Domain Name
+
+ With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
+ in place, the semantics of a wild card domain name owning an
+ NS RRSet has come to be poorly defined. The dilemma relates to
+ a conflict between the rules for synthesis in part 'c' and the
+ fact that the resulting synthesis generates a record for which
+ the zone is not authoritative. In a DNSSEC signed zone, the
+ mechanics of signature management (generation and inclusion
+ in a message) have become unclear.
+
+ Salient points of the working group discussion on this topic is
+ summarized in section 4.2.1.
+
+ As a result of these discussion, there is no definition given for
+ wild card domain names owning an NS RRSet. The semantics are
+ left undefined until there is a clear need to have a set defined,
+ and until there is a clear direction to proceed. Operationally,
+ inclusion of wild card NS RRSets in a zone is discouraged, but
+ not barred.
+
+4.2.1 Discarded Notions
+
+ Prior to DNSSEC, a wild card domain name owning a NS RRSet
+ appeared to be workable, and there are some instances in which
+ it is found in deployments using implementations that support
+ this. Continuing to allow this in the specification is not
+ tenable with DNSSEC. The reason is that the synthesis of the
+ NS RRSet is being done in a zone that has delegated away the
+ responsibility for the name. This "unauthorized" synthesis is
+ not a problem for the base DNS protocol, but DNSSEC, in affirming
+ the authorization model for DNS exposes the problem.
+
+DNSEXT Working Group Expires July 9, 2006 [Page 14]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ Outright banning of wildcards of type NS is also untenable as
+ the DNS protocol does not define how to handle "illegal" data.
+ Implementations may choose not to load a zone, but there is no
+ protocol definition. The lack of the definition is complicated
+ by having to cover dynamic update [RFC 2136], zone transfers,
+ as well as loading at the master server. The case of a client
+ (resolver, caching server) getting a wildcard of type NS in
+ a reply would also have to be considered.
+
+ Given the daunting challenge of a complete definition of how to
+ ban such records, dealing with existing implementations that
+ permit the records today is a further complication. There are
+ uses of wild card domain name owning NS RRSets.
+
+ One compromise proposed would have redefined wildcards of type
+ NS to not be used in synthesis, this compromise fell apart
+ because it would have required significant edits to the DNSSEC
+ signing and validation work. (Again, DNSSEC catches
+ unauthorized data.)
+
+ With no clear consensus forming on the solution to this dilemma,
+ and the realization that wildcards of type NS are a rarity in
+ operations, the best course of action is to leave this open-ended
+ until "it matters."
+
+4.3 CNAME RRSet at a Wild Card Domain Name
+
+ The issue of a CNAME RRSet owned by a wild card domain name has
+ prompted a suggested change to the last paragraph of step 3c of
+ the algorithm in 4.3.2. The changed text appears in section
+ 3.3.3 of this document.
+
+4.4 DNAME RRSet at a Wild Card Domain Name
+
+ Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
+ represents a threat to the coherency of the DNS and is to be
+ avoided or outright rejected. Such a DNAME RRSet represents
+ non-deterministic synthesis of rules fed to different caches.
+ As caches are fed the different rules (in an unpredictable
+ manner) the caches will cease to be coherent. ("As caches
+ are fed" refers to the storage in a cache of records obtained
+ in responses by recursive or iterative servers.)
+
+ For example, assume one cache, responding to a recursive
+ request, obtains the record:
+ "a.b.example. DNAME foo.bar.example.net."
+ and another cache obtains:
+ "b.example. DNAME foo.bar.example.net."
+ both generated from the record:
+ "*.example. DNAME foo.bar.example.net."
+ by an authoritative server.
+
+DNSEXT Working Group Expires July 9, 2006 [Page 15]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ The DNAME specification is not clear on whether DNAME records
+ in a cache are used to rewrite queries. In some interpretations,
+ the rewrite occurs, in some, it is not. Allowing for the
+ occurrence of rewriting, queries for "sub.a.b.example. A" may
+ be rewritten as "sub.foo.bar.tld. A" by the former caching
+ server and may be rewritten as "sub.a.foo.bar.tld. A" by the
+ latter. Coherency is lost, an operational nightmare ensues.
+
+ Another justification for banning or avoiding wildcard DNAME
+ records is the observation that such a record could synthesize
+ a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
+ There is a restriction in the DNAME definition that no domain
+ exist below a DNAME-owning domain, hence, the wildcard DNAME
+ is not to be permitted.
+
+4.5 SRV RRSet at a Wild Card Domain Name
+
+ The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
+ definition of the record, there is some confusion over the term
+ "Name." The definition reads as follows:
+
+# The format of the SRV RR
+...
+# _Service._Proto.Name TTL Class SRV Priority Weight Port Target
+...
+# Name
+# The domain this RR refers to. The SRV RR is unique in that the
+# name one searches for is not this name; the example near the end
+# shows this clearly.
+
+ Do not confuse the definition "Name" with the owner name. I.e.,
+ once removing the _Service and _Proto labels from the owner name
+ of the SRV RRSet, what remains could be a wild card domain name
+ but this is immaterial to the SRV RRSet.
+
+ E.g., If an SRV record is:
+ _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
+
+ *.example is a wild card domain name and although it is the Name
+ of the SRV RR, it is not the owner (domain name). The owner
+ domain name is "_foo._udp.*.example." which is not a wild card
+ domain name.
+
+ The confusion is likely based on the mixture of the specification
+ of the SRV RR and the description of a "use case."
+
+4.6 DS RRSet at a Wild Card Domain Name
+
+ A DS RRSet owned by a wild card domain name is meaningless and
+ harmless. This statement is made in the context that an NS RRSet
+ at a wild card domain name is undefined. At a non-delegation
+
+DNSEXT Working Group Expires July 9, 2006 [Page 16]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ point, a DS RRSet has no value (no corresponding DNSKEY RRSet
+ will be used in DNSSEC validation). If there is a synthesized
+ DS RRSet, it alone will not be very useful as it exists in the
+ context of a delegation point.
+
+4.7 NSEC RRSet at a Wild Card Domain Name
+
+ Wild card domain names in DNSSEC signed zones will have an NSEC
+ RRSet. Synthesis of these records will only occur when the
+ query exactly matches the record. Synthesized NSEC RR's will not
+ be harmful as they will never be used in negative caching or to
+ generate a negative response. [RFC2308]
+
+4.8 RRSIG at a Wild Card Domain Name
+
+ RRSIG records will be present at a wild card domain name in a
+ signed zone, and will be synthesized along with data sought in a
+ query. The fact that the owner name is synthesized is not a
+ problem as the label count in the RRSIG will instruct the
+ verifying code to ignore it.
+
+4.9 Empty Non-terminal Wild Card Domain Name
+
+ If a source of synthesis is an empty non-terminal, then the
+ response will be one of no error in the return code and no RRSet
+ in the answer section.
+
+5. Security Considerations
+
+ This document is refining the specifications to make it more
+ likely that security can be added to DNS. No functional
+ additions are being made, just refining what is considered
+ proper to allow the DNS, security of the DNS, and extending
+ the DNS to be more predictable.
+
+6. IANA Considerations
+
+ None.
+
+7. References
+
+ Normative References
+
+ [RFC20] ASCII Format for Network Interchange, V.G. Cerf,
+ Oct-16-1969
+
+ [RFC1034] Domain Names - Concepts and Facilities,
+ P.V. Mockapetris, Nov-01-1987
+
+ [RFC1035] Domain Names - Implementation and Specification, P.V
+ Mockapetris, Nov-01-1987
+
+DNSEXT Working Group Expires July 9, 2006 [Page 17]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+ [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
+
+ [RFC2119] Key Words for Use in RFCs to Indicate Requirement
+ Levels, S Bradner, March 1997
+
+ [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
+ M. Andrews, March 1998
+
+ [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
+ August 1999.
+
+ [RFC2782] A DNS RR for specifying the location of services (DNS
+ SRV), A. Gulbrandsen, et.al., February 2000
+
+ [RFC4033] DNS Security Introduction and Requirements, R. Arends,
+ et.al., March 2005
+
+ [RFC4034] Resource Records for the DNS Security Extensions,
+ R. Arends, et.al., March 2005
+
+ [RFC4035] Protocol Modifications for the DNS Security Extensions,
+ R. Arends, et.al., March 2005
+
+ Informative References
+
+ [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
+ P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
+ April 1997
+
+8. Editor
+
+ Name: Edward Lewis
+ Affiliation: NeuStar
+ Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
+ Phone: +1-571-434-5468
+ Email: ed.lewis@neustar.biz
+
+ Comments on this document can be sent to the editor or the mailing
+ list for the DNSEXT WG, namedroppers@ops.ietf.org.
+
+9. Others Contributing to the Document
+
+ This document represents the work of a large working group. The
+ editor merely recorded the collective wisdom of the working group.
+
+
+
+
+
+
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 17]
+
+Internet-Draft dnsext-wcard January 9, 2006
+
+10. Trailing Boilerplate
+
+ 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 currently provided by the
+ Internet Society.
+
+Expiration
+
+ This document expires on or about July 9, 2006.
+
+
+
+DNSEXT Working Group Expires July 9, 2006 [Page 19]
diff --git a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
new file mode 100644
index 0000000..0855ba3
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
@@ -0,0 +1,1232 @@
+
+
+
+DNS Operations M. Larson
+Internet-Draft P. Barber
+Expires: August 14, 2006 VeriSign
+ February 10, 2006
+
+
+ Observed DNS Resolution Misbehavior
+ draft-ietf-dnsop-bad-dns-res-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 August 14, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This memo describes DNS iterative resolver behavior that results in a
+ significant query volume sent to the root and top-level domain (TLD)
+ name servers. We offer implementation advice to iterative resolver
+ developers to alleviate these unnecessary queries. The
+ recommendations made in this document are a direct byproduct of
+ observation and analysis of abnormal query traffic patterns seen at
+ two of the thirteen root name servers and all thirteen com/net TLD
+ name servers.
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 1]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ 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].
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. A note about terminology in this memo . . . . . . . . . . 3
+ 2. Observed iterative resolver misbehavior . . . . . . . . . . . 5
+ 2.1. Aggressive requerying for delegation information . . . . . 5
+ 2.1.1. Recommendation . . . . . . . . . . . . . . . . . . . . 6
+ 2.2. Repeated queries to lame servers . . . . . . . . . . . . . 7
+ 2.2.1. Recommendation . . . . . . . . . . . . . . . . . . . . 7
+ 2.3. Inability to follow multiple levels of indirection . . . . 8
+ 2.3.1. Recommendation . . . . . . . . . . . . . . . . . . . . 9
+ 2.4. Aggressive retransmission when fetching glue . . . . . . . 9
+ 2.4.1. Recommendation . . . . . . . . . . . . . . . . . . . . 10
+ 2.5. Aggressive retransmission behind firewalls . . . . . . . . 10
+ 2.5.1. Recommendation . . . . . . . . . . . . . . . . . . . . 11
+ 2.6. Misconfigured NS records . . . . . . . . . . . . . . . . . 11
+ 2.6.1. Recommendation . . . . . . . . . . . . . . . . . . . . 12
+ 2.7. Name server records with zero TTL . . . . . . . . . . . . 12
+ 2.7.1. Recommendation . . . . . . . . . . . . . . . . . . . . 13
+ 2.8. Unnecessary dynamic update messages . . . . . . . . . . . 13
+ 2.8.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14
+ 2.9. Queries for domain names resembling IPv4 addresses . . . . 14
+ 2.9.1. Recommendation . . . . . . . . . . . . . . . . . . . . 14
+ 2.10. Misdirected recursive queries . . . . . . . . . . . . . . 15
+ 2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
+ 2.11. Suboptimal name server selection algorithm . . . . . . . . 15
+ 2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
+ 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
+ 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 5. Security considerations . . . . . . . . . . . . . . . . . . . 19
+ 6. Internationalization considerations . . . . . . . . . . . . . 20
+ 7. Informative References . . . . . . . . . . . . . . . . . . . . 20
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
+ Intellectual Property and Copyright Statements . . . . . . . . . . 22
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 2]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+1. Introduction
+
+ Observation of query traffic received by two root name servers and
+ the thirteen com/net TLD name servers has revealed that a large
+ proportion of the total traffic often consists of "requeries". A
+ requery is the same question (<QNAME, QTYPE, QCLASS>) asked
+ repeatedly at an unexpectedly high rate. We have observed requeries
+ from both a single IP address and multiple IP addresses (i.e., the
+ same query received simultaneously from multiple IP addresses).
+
+ By analyzing requery events we have found that the cause of the
+ duplicate traffic is almost always a deficient iterative resolver,
+ stub resolver or application implementation combined with an
+ operational anomaly. The implementation deficiencies we have
+ identified to date include well-intentioned recovery attempts gone
+ awry, insufficient caching of failures, early abort when multiple
+ levels of indirection must be followed, and aggressive retry by stub
+ resolvers or applications. Anomalies that we have seen trigger
+ requery events include lame delegations, unusual glue records, and
+ anything that makes all authoritative name servers for a zone
+ unreachable (DoS attacks, crashes, maintenance, routing failures,
+ congestion, etc.).
+
+ In the following sections, we provide a detailed explanation of the
+ observed behavior and recommend changes that will reduce the requery
+ rate. None of the changes recommended affects the core DNS protocol
+ specification; instead, this document consists of guidelines to
+ implementors of iterative resolvers.
+
+1.1. A note about terminology in this memo
+
+ To recast an old saying about standards, the nice thing about DNS
+ terms is that there are so many of them to choose from. Writing or
+ talking about DNS can be difficult and cause confusion resulting from
+ a lack of agreed-upon terms for its various components. Further
+ complicating matters are implementations that combine multiple roles
+ into one piece of software, which makes naming the result
+ problematic. An example is the entity that accepts recursive
+ queries, issues iterative queries as necessary to resolve the initial
+ recursive query, caches responses it receives, and which is also able
+ to answer questions about certain zones authoritatively. This entity
+ is an iterative resolver combined with an authoritative name server
+ and is often called a "recursive name server" or a "caching name
+ server".
+
+ This memo is concerned principally with the behavior of iterative
+ resolvers, which are typically found as part of a recursive name
+ server. This memo uses the more precise term "iterative resolver",
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 3]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ because the focus is usually on that component. In instances where
+ the name server role of this entity requires mentioning, this memo
+ uses the term "recursive name server". As an example of the
+ difference, the name server component of a recursive name server
+ receives DNS queries and the iterative resolver component sends
+ queries.
+
+ The advent of IPv6 requires mentioning AAAA records as well as A
+ records when discussing glue. To avoid continuous repetition and
+ qualification, this memo uses the general term "address record" to
+ encompass both A and AAAA records when a particular situation is
+ relevant to both types.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 4]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+2. Observed iterative resolver misbehavior
+
+2.1. Aggressive requerying for delegation information
+
+ There can be times when every name server in a zone's NS RRset is
+ unreachable (e.g., during a network outage), unavailable (e.g., the
+ name server process is not running on the server host) or
+ misconfigured (e.g., the name server is not authoritative for the
+ given zone, also known as "lame"). Consider an iterative resolver
+ that attempts to resolve a query for a domain name in such a zone and
+ discovers that none of the zone's name servers can provide an answer.
+ We have observed a recursive name server implementation whose
+ iterative resolver then verifies the zone's NS RRset in its cache by
+ querying for the zone's delegation information: it sends a query for
+ the zone's NS RRset to one of the parent zone's name servers. (Note
+ that queries with QTYPE=NS are not required by the standard
+ resolution algorithm described in section 4.3.2 of RFC 1034 [2].
+ These NS queries represent this implementation's addition to that
+ algorithm.)
+
+ For example, suppose that "example.com" has the following NS RRset:
+
+ example.com. IN NS ns1.example.com.
+ example.com. IN NS ns2.example.com.
+
+ Upon receipt of a query for "www.example.com" and assuming that
+ neither "ns1.example.com" nor "ns2.example.com" can provide an
+ answer, this iterative resolver implementation immediately queries a
+ "com" zone name server for the "example.com" NS RRset to verify it
+ has the proper delegation information. This implementation performs
+ this query to a zone's parent zone for each recursive query it
+ receives that fails because of a completely unresponsive set of name
+ servers for the target zone. Consider the effect when a popular zone
+ experiences a catastrophic failure of all its name servers: now every
+ recursive query for domain names in that zone sent to this recursive
+ name server implementation results in a query to the failed zone's
+ parent name servers. On one occasion when several dozen popular
+ zones became unreachable, the query load on the com/net name servers
+ increased by 50%.
+
+ We believe this verification query is not reasonable. Consider the
+ circumstances: When an iterative resolver is resolving a query for a
+ domain name in a zone it has not previously searched, it uses the
+ list of name servers in the referral from the target zone's parent.
+ If on its first attempt to search the target zone, none of the name
+ servers in the referral is reachable, a verification query to the
+ parent would be pointless: this query to the parent would come so
+ quickly on the heels of the referral that it would be almost certain
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 5]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ to contain the same list of name servers. The chance of discovering
+ any new information is slim.
+
+ The other possibility is that the iterative resolver successfully
+ contacts one of the target zone's name servers and then caches the NS
+ RRset from the authority section of a response, the proper behavior
+ according to section 5.4.1 of RFC 2181 [3], because the NS RRset from
+ the target zone is more trustworthy than delegation information from
+ the parent zone. If, while processing a subsequent recursive query,
+ the iterative resolver discovers that none of the name servers
+ specified in the cached NS RRset is available or authoritative,
+ querying the parent would be wrong. An NS RRset from the parent zone
+ would now be less trustworthy than data already in the cache.
+
+ For this query of the parent zone to be useful, the target zone's
+ entire set of name servers would have to change AND the former set of
+ name servers would have to be deconfigured or decommissioned AND the
+ delegation information in the parent zone would have to be updated
+ with the new set of name servers, all within the TTL of the target
+ zone's NS RRset. We believe this scenario is uncommon:
+ administrative best practices dictate that changes to a zone's set of
+ name servers happen gradually when at all possible, with servers
+ removed from the NS RRset left authoritative for the zone as long as
+ possible. The scenarios that we can envision that would benefit from
+ the parent requery behavior do not outweigh its damaging effects.
+
+ This section should not be understood to claim that all queries to a
+ zone's parent are bad. In some cases, such queries are not only
+ reasonable but required. Consider the situation when required
+ information, such as the address of a name server (i.e., the address
+ record corresponding to the RDATA of an NS record), has timed out of
+ an iterative resolver's cache before the corresponding NS record. If
+ the name of the name server is below the apex of the zone, then the
+ name server's address record is only available as glue in the parent
+ zone. For example, consider this NS record:
+
+ example.com. IN NS ns.example.com.
+
+ If a cache has this NS record but not the address record for
+ "ns.example.com", it is unable to contact the "example.com" zone
+ directly and must query the "com" zone to obtain the address record.
+ Note, however, that such a query would not have QTYPE=NS according to
+ the standard resolution algorithm.
+
+2.1.1. Recommendation
+
+ An iterative resolver MUST NOT send a query for the NS RRset of a
+ non-responsive zone to any of the name servers for that zone's parent
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 6]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ zone. For the purposes of this injunction, a non-responsive zone is
+ defined as a zone for which every name server listed in the zone's NS
+ RRset:
+
+ 1. is not authoritative for the zone (i.e., lame), or,
+
+ 2. returns a server failure response (RCODE=2), or,
+
+ 3. is dead or unreachable according to section 7.2 of RFC 2308 [4].
+
+2.2. Repeated queries to lame servers
+
+ Section 2.1 describes a catastrophic failure: when every name server
+ for a zone is unable to provide an answer for one reason or another.
+ A more common occurrence is when a subset of a zone's name servers
+ are unavailable or misconfigured. Different failure modes have
+ different expected durations. Some symptoms indicate problems that
+ are potentially transient; for example, various types of ICMP
+ unreachable messages because a name server process is not running or
+ a host or network is unreachable, or a complete lack of a response to
+ a query. Such responses could be the result of a host rebooting or
+ temporary outages; these events don't necessarily require any human
+ intervention and can be reasonably expected to be temporary.
+
+ Other symptoms clearly indicate a condition requiring human
+ intervention, such as lame server: if a name server is misconfigured
+ and not authoritative for a zone delegated to it, it is reasonable to
+ assume that this condition has potential to last longer than
+ unreachability or unresponsiveness. Consequently, repeated queries
+ to known lame servers are not useful. In this case of a condition
+ with potential to persist for a long time, a better practice would be
+ to maintain a list of known lame servers and avoid querying them
+ repeatedly in a short interval.
+
+ It should also be noted, however, that some authoritative name server
+ implementations appear to be lame only for queries of certain types
+ as described in RFC 4074 [5]. In this case, it makes sense to retry
+ the "lame" servers for other types of queries, particularly when all
+ known authoritative name servers appear to be "lame".
+
+2.2.1. Recommendation
+
+ Iterative resolvers SHOULD cache name servers that they discover are
+ not authoritative for zones delegated to them (i.e. lame servers).
+ If this caching is performed, lame servers MUST be cached against the
+ specific query tuple <zone name, class, server IP address>. Zone
+ name can be derived from the owner name of the NS record that was
+ referenced to query the name server that was discovered to be lame.
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 7]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ Implementations that perform lame server caching MUST refrain from
+ sending queries to known lame servers based on a time interval from
+ when the server is discovered to be lame. A minimum interval of
+ thirty minutes is RECOMMENDED.
+
+ An exception to this recommendation occurs if all name servers for a
+ zone are marked lame. In that case, the iterative resolver SHOULD
+ temporarily ignore the servers' lameness status and query one or more
+ servers. This behavior is a workaround for the type-specific
+ lameness issue described in the previous section.
+
+ Implementors should take care not to make lame server avoidance logic
+ overly broad: note that a name server could be lame for a parent zone
+ but not a child zone, e.g., lame for "example.com" but properly
+ authoritative for "sub.example.com". Therefore a name server should
+ not be automatically considered lame for subzones. In the case
+ above, even if a name server is known to be lame for "example.com",
+ it should be queried for QNAMEs at or below "sub.example.com" if an
+ NS record indicates it should be authoritative for that zone.
+
+2.3. Inability to follow multiple levels of indirection
+
+ Some iterative resolver implementations are unable to follow
+ sufficient levels of indirection. For example, consider the
+ following delegations:
+
+ foo.example. IN NS ns1.example.com.
+ foo.example. IN NS ns2.example.com.
+
+ example.com. IN NS ns1.test.example.net.
+ example.com. IN NS ns2.test.example.net.
+
+ test.example.net. IN NS ns1.test.example.net.
+ test.example.net. IN NS ns2.test.example.net.
+
+ An iterative resolver resolving the name "www.foo.example" must
+ follow two levels of indirection, first obtaining address records for
+ "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
+ address records for "ns1.example.com" or "ns2.example.com" in order
+ to query those name servers for the address records of
+ "www.foo.example". While this situation may appear contrived, we
+ have seen multiple similar occurrences and expect more as new generic
+ top-level domains (gTLDs) become active. We anticipate many zones in
+ new gTLDs will use name servers in existing gTLDs, increasing the
+ number of delegations using out-of-zone name servers.
+
+
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 8]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+2.3.1. Recommendation
+
+ Clearly constructing a delegation that relies on multiple levels of
+ indirection is not a good administrative practice. However, the
+ practice is widespread enough to require that iterative resolvers be
+ able to cope with it. Iterative resolvers SHOULD be able to handle
+ arbitrary levels of indirection resulting from out-of-zone name
+ servers. Iterative resolvers SHOULD implement a level-of-effort
+ counter to avoid loops or otherwise performing too much work in
+ resolving pathological cases.
+
+ A best practice that avoids this entire issue of indirection is to
+ name one or more of a zone's name servers in the zone itself. For
+ example, if the zone is named "example.com", consider naming some of
+ the name servers "ns{1,2,...}.example.com" (or similar).
+
+2.4. Aggressive retransmission when fetching glue
+
+ When an authoritative name server responds with a referral, it
+ includes NS records in the authority section of the response.
+ According to the algorithm in section 4.3.2 of RFC 1034 [2], the name
+ server should also "put whatever addresses are available into the
+ additional section, using glue RRs if the addresses are not available
+ from authoritative data or the cache." Some name server
+ implementations take this address inclusion a step further with a
+ feature called "glue fetching". A name server that implements glue
+ fetching attempts to include address records for every NS record in
+ the authority section. If necessary, the name server issues multiple
+ queries of its own to obtain any missing address records.
+
+ Problems with glue fetching can arise in the context of
+ "authoritative-only" name servers, which only serve authoritative
+ data and ignore requests for recursion. Such an entity will not
+ normally generate any queries of its own. Instead it answers non-
+ recursive queries from iterative resolvers looking for information in
+ zones it serves. With glue fetching enabled, however, an
+ authoritative server invokes an iterative resolver to look up an
+ unknown address record to complete the additional section of a
+ response.
+
+ We have observed situations where the iterative resolver of a glue-
+ fetching name server can send queries that reach other name servers,
+ but is apparently prevented from receiving the responses. For
+ example, perhaps the name server is authoritative-only and therefore
+ its administrators expect it to receive only queries and not
+ responses. Perhaps unaware of glue fetching and presuming that the
+ name server's iterative resolver will generate no queries, its
+ administrators place the name server behind a network device that
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 9]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ prevents it from receiving responses. If this is the case, all glue-
+ fetching queries will go answered.
+
+ We have observed name server implementations whose iterative
+ resolvers retry excessively when glue-fetching queries are
+ unanswered. A single com/net name server has received hundreds of
+ queries per second from a single such source. Judging from the
+ specific queries received and based on additional analysis, we
+ believe these queries result from overly aggressive glue fetching.
+
+2.4.1. Recommendation
+
+ Implementers whose name servers support glue fetching SHOULD take
+ care to avoid sending queries at excessive rates. Implementations
+ SHOULD support throttling logic to detect when queries are sent but
+ no responses are received.
+
+2.5. Aggressive retransmission behind firewalls
+
+ A common occurrence and one of the largest sources of repeated
+ queries at the com/net and root name servers appears to result from
+ resolvers behind misconfigured firewalls. In this situation, an
+ iterative resolver is apparently allowed to send queries through a
+ firewall to other name servers, but not receive the responses. The
+ result is more queries than necessary because of retransmission, all
+ of which are useless because the responses are never received. Just
+ as with the glue-fetching scenario described in Section 2.4, the
+ queries are sometimes sent at excessive rates. To make matters
+ worse, sometimes the responses, sent in reply to legitimate queries,
+ trigger an alarm on the originator's intrusion detection system. We
+ are frequently contacted by administrators responding to such alarms
+ who believe our name servers are attacking their systems.
+
+ Not only do some resolvers in this situation retransmit queries at an
+ excessive rate, but they continue to do so for days or even weeks.
+ This scenario could result from an organization with multiple
+ recursive name servers, only a subset of whose iterative resolvers'
+ traffic is improperly filtered in this manner. Stub resolvers in the
+ organization could be configured to query multiple recursive name
+ servers. Consider the case where a stub resolver queries a filtered
+ recursive name server first. The iterative resolver of this
+ recursive name server sends one or more queries whose replies are
+ filtered, so it can't respond to the stub resolver, which times out.
+ Then the stub resolver retransmits to a recursive name server that is
+ able to provide an answer. Since resolution ultimately succeeds the
+ underlying problem might not be recognized or corrected. A popular
+ stub resolver implementation has a very aggressive retransmission
+ schedule, including simultaneous queries to multiple recursive name
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 10]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ servers, which could explain how such a situation could persist
+ without being detected.
+
+2.5.1. Recommendation
+
+ The most obvious recommendation is that administrators SHOULD take
+ care not to place iterative resolvers behind a firewall that allows
+ queries to pass through but not the resulting replies.
+
+ Iterative resolvers SHOULD take care to avoid sending queries at
+ excessive rates. Implementations SHOULD support throttling logic to
+ detect when queries are sent but no responses are received.
+
+2.6. Misconfigured NS records
+
+ Sometimes a zone administrator forgets to add the trailing dot on the
+ domain names in the RDATA of a zone's NS records. Consider this
+ fragment of the zone file for "example.com":
+
+ $ORIGIN example.com.
+ example.com. 3600 IN NS ns1.example.com ; Note missing
+ example.com. 3600 IN NS ns2.example.com ; trailing dots
+
+ The zone's authoritative servers will parse the NS RDATA as
+ "ns1.example.com.example.com" and "ns2.example.com.example.com" and
+ return NS records with this incorrect RDATA in responses, including
+ typically the authority section of every response containing records
+ from the "example.com" zone.
+
+ Now consider a typical sequence of queries. An iterative resolver
+ attempting to resolve address records for "www.example.com" with no
+ cached information for this zone will query a "com" authoritative
+ server. The "com" server responds with a referral to the
+ "example.com" zone, consisting of NS records with valid RDATA and
+ associated glue records. (This example assumes that the
+ "example.com" zone delegation information is correct in the "com"
+ zone.) The iterative resolver caches the NS RRset from the "com"
+ server and follows the referral by querying one of the "example.com"
+ authoritative servers. This server responds with the
+ "www.example.com" address record in the answer section and,
+ typically, the "example.com" NS records in the authority section and,
+ if space in the message remains, glue address records in the
+ additional section. According to Section 5.4 of RFC 2181 [3], NS
+ records in the authority section of an authoritative answer are more
+ trustworthy than NS records from the authority section of a non-
+ authoritative answer. Thus the "example.com" NS RRset just received
+ from the "example.com" authoritative server overrides the
+ "example.com" NS RRset received moments ago from the "com"
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 11]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ authoritative server.
+
+ But the "example.com" zone contains the erroneous NS RRset as shown
+ in the example above. Subsequent queries for names in "example.com"
+ will cause the iterative resolver to attempt to use the incorrect NS
+ records and so it will try to resolve the nonexistent names
+ "ns1.example.com.example.com" and "ns2.example.com.example.com". In
+ this example, since all of the zone's name servers are named in the
+ zone itself (i.e., "ns1.example.com.example.com" and
+ "ns2.example.com.example.com" both end in "example.com") and all are
+ bogus, the iterative resolver cannot reach any "example.com" name
+ servers. Therefore attempts to resolve these names result in address
+ record queries to the "com" authoritative servers. Queries for such
+ obviously bogus glue address records occur frequently at the com/net
+ name servers.
+
+2.6.1. Recommendation
+
+ An authoritative server can detect this situation. A trailing dot
+ missing from an NS record's RDATA always results by definition in a
+ name server name that exists somewhere under the apex of the zone the
+ NS record appears in. Note that further levels of delegation are
+ possible, so a missing trailing dot could inadvertently create a name
+ server name that actually exists in a subzone.
+
+ An authoritative name server SHOULD issue a warning when one of a
+ zone's NS records references a name server below the zone's apex when
+ a corresponding address record does not exist in the zone AND there
+ are no delegated subzones where the address record could exist.
+
+2.7. Name server records with zero TTL
+
+ Sometimes a popular com/net subdomain's zone is configured with a TTL
+ of zero on the zone's NS records, which prohibits these records from
+ being cached and will result in a higher query volume to the zone's
+ authoritative servers. The zone's administrator should understand
+ the consequences of such a configuration and provision resources
+ accordingly. A zero TTL on the zone's NS RRset, however, carries
+ additional consequences beyond the zone itself: if an iterative
+ resolver cannot cache a zone's NS records because of a zero TTL, it
+ will be forced to query that zone's parent's name servers each time
+ it resolves a name in the zone. The com/net authoritative servers do
+ see an increased query load when a popular com/net subdomain's zone
+ is configured with a TTL of zero on the zone's NS records.
+
+ A zero TTL on an RRset expected to change frequently is extreme but
+ permissible. A zone's NS RRset is a special case, however, because
+ changes to it must be coordinated with the zone's parent. In most
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 12]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ zone parent/child relationships we are aware of, there is typically
+ some delay involved in effecting changes. Further, changes to the
+ set of a zone's authoritative name servers (and therefore to the
+ zone's NS RRset) are typically relatively rare: providing reliable
+ authoritative service requires a reasonably stable set of servers.
+ Therefore an extremely low or zero TTL on a zone's NS RRset rarely
+ makes sense, except in anticipation of an upcoming change. In this
+ case, when the zone's administrator has planned a change and does not
+ want iterative resolvers throughout the Internet to cache the NS
+ RRset for a long period of time, a low TTL is reasonable.
+
+2.7.1. Recommendation
+
+ Because of the additional load placed on a zone's parent's
+ authoritative servers resulting from a zero TTL on a zone's NS RRset,
+ under such circumstances authoritative name servers SHOULD issue a
+ warning when loading a zone.
+
+2.8. Unnecessary dynamic update messages
+
+ The UPDATE message specified in RFC 2136 [6] allows an authorized
+ agent to update a zone's data on an authoritative name server using a
+ DNS message sent over the network. Consider the case of an agent
+ desiring to add a particular resource record. Because of zone cuts,
+ the agent does not necessarily know the proper zone to which the
+ record should be added. The dynamic update process requires that the
+ agent determine the appropriate zone so the UPDATE message can be
+ sent to one of the zone's authoritative servers (typically the
+ primary master as specified in the zone's SOA MNAME field).
+
+ The appropriate zone to update is the closest enclosing zone, which
+ cannot be determined only by inspecting the domain name of the record
+ to be updated, since zone cuts can occur anywhere. One way to
+ determine the closest enclosing zone entails walking up the name
+ space tree by sending repeated UPDATE messages until success. For
+ example, consider an agent attempting to add an address record with
+ the name "foo.bar.example.com". The agent could first attempt to
+ update the "foo.bar.example.com" zone. If the attempt failed, the
+ update could be directed to the "bar.example.com" zone, then the
+ "example.com" zone, then the "com" zone, and finally the root zone.
+
+ A popular dynamic agent follows this algorithm. The result is many
+ UPDATE messages received by the root name servers, the com/net
+ authoritative servers, and presumably other TLD authoritative
+ servers. A valid question is why the algorithm proceeds to send
+ updates all the way to TLD and root name servers. This behavior is
+ not entirely unreasonable: in enterprise DNS architectures with an
+ "internal root" design, there could conceivably be private, non-
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 13]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ public TLD or root zones that would be the appropriate targets for a
+ dynamic update.
+
+ A significant deficiency with this algorithm is that knowledge of a
+ given UPDATE message's failure is not helpful in directing future
+ UPDATE messages to the appropriate servers. A better algorithm would
+ be to find the closest enclosing zone by walking up the name space
+ with queries for SOA or NS rather than "probing" with UPDATE
+ messages. Once the appropriate zone is found, an UPDATE message can
+ be sent. In addition, the results of these queries can be cached to
+ aid in determining closest enclosing zones for future updates. Once
+ the closest enclosing zone is determined with this method, the update
+ will either succeed or fail and there is no need to send further
+ updates to higher-level zones. The important point is that walking
+ up the tree with queries yields cacheable information, whereas
+ walking up the tree by sending UPDATE messages does not.
+
+2.8.1. Recommendation
+
+ Dynamic update agents SHOULD send SOA or NS queries to progressively
+ higher-level names to find the closest enclosing zone for a given
+ name to update. Only after the appropriate zone is found should the
+ client send an UPDATE message to one of the zone's authoritative
+ servers. Update clients SHOULD NOT "probe" using UPDATE messages by
+ walking up the tree to progressively higher-level zones.
+
+2.9. Queries for domain names resembling IPv4 addresses
+
+ The root name servers receive a significant number of A record
+ queries where the QNAME looks like an IPv4 address. The source of
+ these queries is unknown. It could be attributed to situations where
+ a user believes an application will accept either a domain name or an
+ IP address in a given configuration option. The user enters an IP
+ address, but the application assumes any input is a domain name and
+ attempts to resolve it, resulting in an A record lookup. There could
+ also be applications that produce such queries in a misguided attempt
+ to reverse map IP addresses.
+
+ These queries result in Name Error (RCODE=3) responses. An iterative
+ resolver can negatively cache such responses, but each response
+ requires a separate cache entry, i.e., a negative cache entry for the
+ domain name "192.0.2.1" does not prevent a subsequent query for the
+ domain name "192.0.2.2".
+
+2.9.1. Recommendation
+
+ It would be desirable for the root name servers not to have to answer
+ these queries: they unnecessarily consume CPU resources and network
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 14]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ bandwidth. A possible solution is to delegate these numeric TLDs
+ from the root zone to a separate set of servers to absorb the
+ traffic. The "black hole servers" used by the AS 112 Project [8],
+ which are currently delegated the in-addr.arpa zones corresponding to
+ RFC 1918 [7] private use address space, would be a possible choice to
+ receive these delegations. Of course, the proper and usual root zone
+ change procedures would have to be followed to make such a change to
+ the root zone.
+
+2.10. Misdirected recursive queries
+
+ The root name servers receive a significant number of recursive
+ queries (i.e., queries with the RD bit set in the header). Since
+ none of the root servers offers recursion, the servers' response in
+ such a situation ignores the request for recursion and the response
+ probably does not contain the data the querier anticipated. Some of
+ these queries result from users configuring stub resolvers to query a
+ root server. (This situation is not hypothetical: we have received
+ complaints from users when this configuration does not work as
+ hoped.) Of course, users should not direct stub resolvers to use
+ name servers that do not offer recursion, but we are not aware of any
+ stub resolver implementation that offers any feedback to the user
+ when so configured, aside from simply "not working".
+
+2.10.1. Recommendation
+
+ When the IP address of a name server that supposedly offers recursion
+ is configured in a stub resolver using an interactive user interface,
+ the resolver could send a test query to verify that the server indeed
+ supports recursion (i.e., verify that the response has the RA bit set
+ in the header). The user could be immediately notified if the server
+ is non-recursive.
+
+ The stub resolver could also report an error, either through a user
+ interface or in a log file, if the queried server does not support
+ recursion. Error reporting SHOULD be throttled to avoid a
+ notification or log message for every response from a non-recursive
+ server.
+
+2.11. Suboptimal name server selection algorithm
+
+ An entire document could be devoted to the topic of problems with
+ different implementations of the recursive resolution algorithm. The
+ entire process of recursion is woefully under specified, requiring
+ each implementor to design an algorithm. Sometimes implementors make
+ poor design choices that could be avoided if a suggested algorithm
+ and best practices were documented, but that is a topic for another
+ document.
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 15]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+ Some deficiencies cause significant operational impact and are
+ therefore worth mentioning here. One of these is name server
+ selection by an iterative resolver. When an iterative resolver wants
+ to contact one of a zone's authoritative name servers, how does it
+ choose from the NS records listed in the zone's NS RRset? If the
+ selection mechanism is suboptimal, queries are not spread evenly
+ among a zone's authoritative servers. The details of the selection
+ mechanism are up to the implementor, but we offer some suggestions.
+
+2.11.1. Recommendation
+
+ This list is not conclusive, but reflects the changes that would
+ produce the most impact in terms of reducing disproportionate query
+ load among a zone's authoritative servers. I.e., these changes would
+ help spread the query load evenly.
+
+ o Do not make assumptions based on NS RRset order: all NS RRs SHOULD
+ be treated equally. (In the case of the "com" zone, for example,
+ most of the root servers return the NS record for "a.gtld-
+ servers.net" first in the authority section of referrals.
+ Apparently as a result, this server receives disproportionately
+ more traffic than the other 12 authoritative servers for "com".)
+
+ o Use all NS records in an RRset. (For example, we are aware of
+ implementations that hard-coded information for a subset of the
+ root servers.)
+
+ o Maintain state and favor the best-performing of a zone's
+ authoritative servers. A good definition of performance is
+ response time. Non-responsive servers can be penalized with an
+ extremely high response time.
+
+ o Do not lock onto the best-performing of a zone's name servers. An
+ iterative resolver SHOULD periodically check the performance of
+ all of a zone's name servers to adjust its determination of the
+ best-performing one.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 16]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+3. Acknowledgments
+
+ The authors would like to thank the following people for their
+ comments that improved this document: Andras Salamon, Dave Meyer,
+ Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
+ Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein. We
+ apologize if we have omitted anyone; any oversight was unintentional.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 17]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+4. IANA considerations
+
+ There are no new IANA considerations introduced by this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 18]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+5. Security considerations
+
+ The iterative resolver misbehavior discussed in this document exposes
+ the root and TLD name servers to increased risk of both intentional
+ and unintentional denial of service attacks.
+
+ We believe that implementation of the recommendations offered in this
+ document will reduce the amount of unnecessary traffic seen at root
+ and TLD name servers, thus reducing the opportunity for an attacker
+ to use such queries to his or her advantage.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 19]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+6. Internationalization considerations
+
+ There are no new internationalization considerations introduced by
+ this memo.
+
+7. Informative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [3] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
+ RFC 2181, July 1997.
+
+ [4] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+ RFC 2308, March 1998.
+
+ [5] Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
+ Queries for IPv6 Addresses", RFC 4074, May 2005.
+
+ [6] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
+ Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+ April 1997.
+
+ [7] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
+ Lear, "Address Allocation for Private Internets", BCP 5,
+ RFC 1918, February 1996.
+
+ [8] <http://www.as112.net>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 20]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 2006
+
+
+Authors' Addresses
+
+ Matt Larson
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ Email: mlarson@verisign.com
+
+
+ Piet Barber
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Dulles, VA 20166-6503
+ USA
+
+ Email: pbarber@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 21]
+
+Internet-Draft Observed DNS Resolution Misbehavior February 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.
+
+
+
+
+Larson & Barber Expires August 14, 2006 [Page 22]
+
diff --git a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
new file mode 100644
index 0000000..8ca68a8
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
@@ -0,0 +1,2016 @@
+
+
+
+DNSOP O. Kolkman
+Internet-Draft R. Gieben
+Obsoletes: 2541 (if approved) NLnet Labs
+Expires: September 7, 2006 March 6, 2006
+
+
+ DNSSEC Operational Practices
+ draft-ietf-dnsop-dnssec-operational-practices-08.txt
+
+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 September 7, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes a set of practices for operating the DNS with
+ security extensions (DNSSEC). The target audience is zone
+ administrators deploying DNSSEC.
+
+ The document discusses operational aspects of using keys and
+ signatures in the DNS. It discusses issues as key generation, key
+ storage, signature generation, key rollover and related policies.
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 1]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ This document obsoletes RFC 2541, as it covers more operational
+ ground and gives more up to date requirements with respect to key
+ sizes and the new DNSSEC specification.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. The Use of the Term 'key' . . . . . . . . . . . . . . . . 4
+ 1.2. Time Definitions . . . . . . . . . . . . . . . . . . . . . 5
+ 2. Keeping the Chain of Trust Intact . . . . . . . . . . . . . . 5
+ 3. Keys Generation and Storage . . . . . . . . . . . . . . . . . 6
+ 3.1. Zone and Key Signing Keys . . . . . . . . . . . . . . . . 6
+ 3.1.1. Motivations for the KSK and ZSK Separation . . . . . . 7
+ 3.1.2. KSKs for High Level Zones . . . . . . . . . . . . . . 8
+ 3.2. Key Generation . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.3. Key Effectivity Period . . . . . . . . . . . . . . . . . . 9
+ 3.4. Key Algorithm . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.5. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.6. Private Key Storage . . . . . . . . . . . . . . . . . . . 12
+ 4. Signature generation, Key Rollover and Related Policies . . . 12
+ 4.1. Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12
+ 4.1.1. Time Considerations . . . . . . . . . . . . . . . . . 13
+ 4.2. Key Rollovers . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.2.1. Zone Signing Key Rollovers . . . . . . . . . . . . . . 15
+ 4.2.2. Key Signing Key Rollovers . . . . . . . . . . . . . . 19
+ 4.2.3. Difference Between ZSK and KSK Rollovers . . . . . . . 20
+ 4.2.4. Automated Key Rollovers . . . . . . . . . . . . . . . 21
+ 4.3. Planning for Emergency Key Rollover . . . . . . . . . . . 22
+ 4.3.1. KSK Compromise . . . . . . . . . . . . . . . . . . . . 22
+ 4.3.2. ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24
+ 4.3.3. Compromises of Keys Anchored in Resolvers . . . . . . 24
+ 4.4. Parental Policies . . . . . . . . . . . . . . . . . . . . 24
+ 4.4.1. Initial Key Exchanges and Parental Policies
+ Considerations . . . . . . . . . . . . . . . . . . . . 24
+ 4.4.2. Storing Keys or Hashes? . . . . . . . . . . . . . . . 25
+ 4.4.3. Security Lameness . . . . . . . . . . . . . . . . . . 25
+ 4.4.4. DS Signature Validity Period . . . . . . . . . . . . . 26
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 28
+ Appendix A. Terminology . . . . . . . . . . . . . . . . . . . . . 29
+ Appendix B. Zone Signing Key Rollover Howto . . . . . . . . . . . 30
+ Appendix C. Typographic Conventions . . . . . . . . . . . . . . . 31
+ Appendix D. Document Details and Changes . . . . . . . . . . . . 33
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 2]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ D.1. draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33
+ D.2. draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33
+ D.3. draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33
+ D.4. draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33
+ D.5. draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34
+ D.6. draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34
+ D.7. draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34
+ D.8. draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34
+ D.9. draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
+ Intellectual Property and Copyright Statements . . . . . . . . . . 36
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 3]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+1. Introduction
+
+ This document describes how to run a DNSSEC (DNS SECure) enabled
+ environment. It is intended for operators who have knowledge of the
+ DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC. See
+ RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the
+ newly introduced Resource Records and finally RFC 4035 [6] for the
+ protocol changes.
+
+ During workshops and early operational deployment tests, operators
+ and system administrators have gained experience about operating the
+ DNS with security extensions (DNSSEC). This document translates
+ these experiences into a set of practices for zone administrators.
+ At the time of writing, there exists very little experience with
+ DNSSEC in production environments; this document should therefore
+ explicitly not be seen as representing 'Best Current Practices'.
+
+ The procedures herein are focused on the maintenance of signed zones
+ (i.e. signing and publishing zones on authoritative servers). It is
+ intended that maintenance of zones such as re-signing or key
+ rollovers be transparent to any verifying clients on the Internet.
+
+ The structure of this document is as follows. In Section 2 we
+ discuss the importance of keeping the "chain of trust" intact.
+ Aspects of key generation and storage of private keys are discussed
+ in Section 3; the focus in this section is mainly on the private part
+ of the key(s). Section 4 describes considerations concerning the
+ public part of the keys. Since these public keys appear in the DNS
+ one has to take into account all kinds of timing issues, which are
+ discussed in Section 4.1. Section 4.2 and Section 4.3 deal with the
+ rollover, or supercession, of keys. Finally Section 4.4 discusses
+ considerations on how parents deal with their children's public keys
+ in order to maintain chains of trust.
+
+ The typographic conventions used in this document are explained in
+ Appendix C.
+
+ Since this is a document with operational suggestions and there are
+ no protocol specifications, the RFC 2119 [9] language does not apply.
+
+ This document obsoletes RFC 2541 [12].
+
+1.1. The Use of the Term 'key'
+
+ It is assumed that the reader is familiar with the concept of
+ asymmetric keys on which DNSSEC is based (Public Key Cryptography
+ [18]). Therefore, this document will use the term 'key' rather
+ loosely. Where it is written that 'a key is used to sign data' it is
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 4]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ assumed that the reader understands that it is the private part of
+ the key pair that is used for signing. It is also assumed that the
+ reader understands that the public part of the key pair is published
+ in the DNSKEY resource record and that it is the public part that is
+ used in key exchanges.
+
+1.2. Time Definitions
+
+ In this document we will be using a number of time related terms.
+ The following definitions apply:
+ o "Signature validity period"
+ The period that a signature is valid. It starts at the time
+ specified in the signature inception field of the RRSIG RR and
+ ends at the time specified in the expiration field of the RRSIG
+ RR.
+ o "Signature publication period"
+ Time after which a signature (made with a specific key) is
+ replaced with a new signature (made with the same key). This
+ replacement takes place by publishing the relevant RRSIG in the
+ master zone file.
+ After one stops publishing an RRSIG in a zone it may take a
+ while before the RRSIG has expired from caches and has actually
+ been removed from the DNS.
+ o "Key effectivity period"
+ The period during which a key pair is expected to be effective.
+ This period is defined as the time between the first inception
+ time stamp and the last expiration date of any signature made
+ with this key, regardless of any discontinuity in the use of
+ the key.
+ The key effectivity period can span multiple signature validity
+ periods.
+ o "Maximum/Minimum Zone Time to Live (TTL)"
+ The maximum or minimum value of the TTLs from the complete set
+ of RRs in a zone. Note that the minimum TTL is not the same as
+ the MINIMUM field in the SOA RR. See [11] for more
+ information.
+
+
+2. Keeping the Chain of Trust Intact
+
+ Maintaining a valid chain of trust is important because broken chains
+ of trust will result in data being marked as Bogus (as defined in [4]
+ section 5), which may cause entire (sub)domains to become invisible
+ to verifying clients. The administrators of secured zones have to
+ realize that their zone is, to verifying clients, part of a chain of
+ trust.
+
+ As mentioned in the introduction, the procedures herein are intended
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 5]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ to ensure that maintenance of zones, such as re-signing or key
+ rollovers, will be transparent to the verifying clients on the
+ Internet.
+
+ Administrators of secured zones will have to keep in mind that data
+ published on an authoritative primary server will not be immediately
+ seen by verifying clients; it may take some time for the data to be
+ transferred to other secondary authoritative nameservers and clients
+ may be fetching data from caching non-authoritative servers. In this
+ light it is good to note that the time for a zone transfer from
+ master to slave is negligible when using NOTIFY [8] and IXFR [7],
+ increasing by reliance on AXFR, and more if you rely on the SOA
+ timing parameters for zone refresh.
+
+ For the verifying clients it is important that data from secured
+ zones can be used to build chains of trust regardless of whether the
+ data came directly from an authoritative server, a caching nameserver
+ or some middle box. Only by carefully using the available timing
+ parameters can a zone administrator assure that the data necessary
+ for verification can be obtained.
+
+ The responsibility for maintaining the chain of trust is shared by
+ administrators of secured zones in the chain of trust. This is most
+ obvious in the case of a 'key compromise' when a trade off between
+ maintaining a valid chain of trust and replacing the compromised keys
+ as soon as possible must be made. Then zone administrators will have
+ to make a trade off, between keeping the chain of trust intact -
+ thereby allowing for attacks with the compromised key - or to
+ deliberately break the chain of trust and making secured sub domains
+ invisible to security aware resolvers. Also see Section 4.3.
+
+
+3. Keys Generation and Storage
+
+ This section describes a number of considerations with respect to the
+ security of keys. It deals with the generation, effectivity period,
+ size and storage of private keys.
+
+3.1. Zone and Key Signing Keys
+
+ The DNSSEC validation protocol does not distinguish between different
+ types of DNSKEYs. All DNSKEYs can be used during the validation. In
+ practice operators use Key Signing and Zone Signing Keys and use the
+ so-called (Secure Entry Point) SEP [3] flag to distinguish between
+ them during operations. The dynamics and considerations are
+ discussed below.
+
+ To make zone re-signing and key rollover procedures easier to
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 6]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ implement, it is possible to use one or more keys as Key Signing Keys
+ (KSK). These keys will only sign the apex DNSKEY RRSet in a zone.
+ Other keys can be used to sign all the RRSets in a zone and are
+ referred to as Zone Signing Keys (ZSK). In this document we assume
+ that KSKs are the subset of keys that are used for key exchanges with
+ the parent and potentially for configuration as trusted anchors - the
+ SEP keys. In this document we assume a one-to-one mapping between
+ KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
+
+3.1.1. Motivations for the KSK and ZSK Separation
+
+ Differentiating between the KSK and ZSK functions has several
+ advantages:
+
+ o No parent/child interaction is required when ZSKs are updated.
+ o The KSK can be made stronger (i.e. using more bits in the key
+ material). This has little operational impact since it is only
+ used to sign a small fraction of the zone data. Also the KSK is
+ only used to verify the zone's key set, not for other RRSets in
+ the zone.
+ o As the KSK is only used to sign a key set, which is most probably
+ updated less frequently than other data in the zone, it can be
+ stored separately from and in a safer location than the ZSK.
+ o A KSK can have a longer key effectivity period.
+
+ For almost any method of key management and zone signing the KSK is
+ used less frequently than the ZSK. Once a key set is signed with the
+ KSK all the keys in the key set can be used as ZSK. If a ZSK is
+ compromised, it can be simply dropped from the key set. The new key
+ set is then re-signed with the KSK.
+
+ Given the assumption that for KSKs the SEP flag is set, the KSK can
+ be distinguished from a ZSK by examining the flag field in the DNSKEY
+ RR. If the flag field is an odd number it is a KSK. If it is an
+ even number it is a ZSK.
+
+ The zone signing key can be used to sign all the data in a zone on a
+ regular basis. When a zone signing key is to be rolled, no
+ interaction with the parent is needed. This allows for "Signature
+ Validity Periods" on the order of days.
+
+ The key signing key is only to be used to sign the DNSKEY RRs in a
+ zone. If a key signing key is to be rolled over, there will be
+ interactions with parties other than the zone administrator. These
+ can include the registry of the parent zone or administrators of
+ verifying resolvers that have the particular key configured as secure
+ entry points. Hence, the key effectivity period of these keys can
+ and should be made much longer. Although, given a long enough key,
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 7]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ the Key Effectivity Period can be on the order of years we suggest
+ planning for a key effectivity of the order of a few months so that a
+ key rollover remains an operational routine.
+
+3.1.2. KSKs for High Level Zones
+
+ Higher level zones are generally more sensitive than lower level
+ zones. Anyone controlling or breaking the security of a zone thereby
+ obtains authority over all of its sub domains (except in the case of
+ resolvers that have locally configured the public key of a sub
+ domain, in which case this, and only this, sub domain wouldn't be
+ affected by the compromise of the parent zone). Therefore, extra
+ care should be taken with high level zones and strong keys should
+ used.
+
+ The root zone is the most critical of all zones. Someone controlling
+ or compromising the security of the root zone would control the
+ entire DNS name space of all resolvers using that root zone (except
+ in the case of resolvers that have locally configured the public key
+ of a sub domain). Therefore, the utmost care must be taken in the
+ securing of the root zone. The strongest and most carefully handled
+ keys should be used. The root zone private key should always be kept
+ off line.
+
+ Many resolvers will start at a root server for their access to and
+ authentication of DNS data. Securely updating the trust anchors in
+ an enormous population of resolvers around the world will be
+ extremely difficult.
+
+3.2. Key Generation
+
+ Careful generation of all keys is a sometimes overlooked but
+ absolutely essential element in any cryptographically secure system.
+ The strongest algorithms used with the longest keys are still of no
+ use if an adversary can guess enough to lower the size of the likely
+ key space so that it can be exhaustively searched. Technical
+ suggestions for the generation of random keys will be found in RFC
+ 4086 [15]. One should carefully assess if the random number
+ generator used during key generation adheres to these suggestions.
+
+ Keys with a long effectivity period are particularly sensitive as
+ they will represent a more valuable target and be subject to attack
+ for a longer time than short period keys. It is strongly recommended
+ that long term key generation occur off-line in a manner isolated
+ from the network via an air gap or, at a minimum, high level secure
+ hardware.
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 8]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+3.3. Key Effectivity Period
+
+ For various reasons keys in DNSSEC need to be changed once in a
+ while. The longer a key is in use, the greater the probability that
+ it will have been compromised through carelessness, accident,
+ espionage, or cryptanalysis. Furthermore when key rollovers are too
+ rare an event, they will not become part of the operational habit and
+ there is risk that nobody on-site will remember the procedure for
+ rollover when the need is there.
+
+ From a purely operational perspective a reasonable key effectivity
+ period for Key Signing Keys is 13 months, with the intent to replace
+ them after 12 months. An intended key effectivity period of a month
+ is reasonable for Zone Signing Keys.
+
+ For key sizes that matches these effectivity periods see Section 3.5.
+
+ As argued in Section 3.1.2 securely updating trust anchors will be
+ extremely difficult. On the other hand the "operational habit"
+ argument does also apply to trust anchor reconfiguration. If a short
+ key-effectivity period is used and the trust anchor configuration has
+ to be revisited on a regular basis the odds that the configuration
+ tends to be forgotten is smaller. The trade-off is against a system
+ that is so dynamic that administrators of the validating clients will
+ not be able to follow the modifications.
+
+ Key effectivity periods can be made very short, as in the order of a
+ few minutes. But when replacing keys one has to take the
+ considerations from Section 4.1 and Section 4.2 into account.
+
+3.4. Key Algorithm
+
+ There are currently three different types of algorithms that can be
+ used in DNSSEC: RSA, DSA and elliptic curve cryptography. The latter
+ is fairly new and has yet to be standardized for usage in DNSSEC.
+
+ RSA has been developed in an open and transparent manner. As the
+ patent on RSA expired in 2000, its use is now also free.
+
+ DSA has been developed by NIST. The creation of signatures takes
+ roughly the same time as with RSA, but is 10 to 40 times as slow for
+ verification [18].
+
+ We suggest the use of RSA/SHA-1 as the preferred algorithm for the
+ key. The current known attacks on RSA can be defeated by making your
+ key longer. As the MD5 hashing algorithm is showing (theoretical)
+ cracks, we recommend the usage of SHA-1.
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 9]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ At the time of publication it is known that the SHA-1 hash has
+ cryptanalysis issues. There is work in progress on addressing these
+ issues. We recommend the use of public key algorithms based on
+ hashes stronger than SHA-1, e.g. SHA-256, as soon as these
+ algorithms are available in protocol specifications (See [20] and
+ [21] ) and implementations.
+
+3.5. Key Sizes
+
+ When choosing key sizes, zone administrators will need to take into
+ account how long a key will be used, how much data will be signed
+ during the key publication period (See Section 8.10 of [18]) and,
+ optionally, how large the key size of the parent is. As the chain of
+ trust really is "a chain", there is not much sense in making one of
+ the keys in the chain several times larger then the others. As
+ always, it's the weakest link that defines the strength of the entire
+ chain. Also see Section 3.1.1 for a discussion of how keys serving
+ different roles (ZSK v. KSK) may need different key sizes.
+
+ Generating a key of the correct size is a difficult problem, RFC 3766
+ [14] tries to deal with that problem. The first part of the
+ selection procedure in Section 1 of the RFC states:
+
+ 1. Determine the attack resistance necessary to satisfy the
+ security requirements of the application. Do this by
+ estimating the minimum number of computer operations that
+ the attacker will be forced to do in order to compromise
+ the security of the system and then take the logarithm base
+ two of that number. Call that logarithm value "n".
+
+ A 1996 report recommended 90 bits as a good all-around choice
+ for system security. The 90 bit number should be increased
+ by about 2/3 bit/year, or about 96 bits in 2005.
+
+ [14] goes on to explain how this number "n" can be used to calculate
+ the key sizes in public key cryptography. This culminated in the
+ table given below (slightly modified for our purpose):
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 10]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ +-------------+-----------+--------------+
+ | System | | |
+ | requirement | Symmetric | RSA or DSA |
+ | for attack | key size | modulus size |
+ | resistance | (bits) | (bits) |
+ | (bits) | | |
+ +-------------+-----------+--------------+
+ | 70 | 70 | 947 |
+ | 80 | 80 | 1228 |
+ | 90 | 90 | 1553 |
+ | 100 | 100 | 1926 |
+ | 150 | 150 | 4575 |
+ | 200 | 200 | 8719 |
+ | 250 | 250 | 14596 |
+ +-------------+-----------+--------------+
+
+ The key sizes given are rather large. This is because these keys are
+ resilient against a trillionaire attacker. Assuming this rich
+ attacker will not attack your key and that the key is rolled over
+ once a year, we come to the following recommendations about KSK
+ sizes; 1024 bits low value domains, 1300 for medium value and 2048
+ for the high value domains.
+
+ Whether a domain is of low, medium, high value depends solely on the
+ views of the zone owner. One could for instance view leaf nodes in
+ the DNS as of low value and TLDs or the root zone of high value. The
+ suggested key sizes should be safe for the next 5 years.
+
+ As ZSKs can be rolled over more easily (and thus more often) the key
+ sizes can be made smaller. But as said in the introduction of this
+ paragraph, making the ZSKs' key sizes too small (in relation to the
+ KSKs' sizes) doesn't make much sense. Try to limit the difference in
+ size to about 100 bits.
+
+ Note that nobody can see into the future, and that these key sizes
+ are only provided here as a guide. Further information can be found
+ in [17] and Section 7.5 of [18]. It should be noted though that [17]
+ is already considered overly optimistic about what key sizes are
+ considered safe.
+
+ One final note concerning key sizes. Larger keys will increase the
+ sizes of the RRSIG and DNSKEY records and will therefore increase the
+ chance of DNS UDP packet overflow. Also the time it takes to
+ validate and create RRSIGs increases with larger keys, so don't
+ needlessly double your key sizes.
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 11]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+3.6. Private Key Storage
+
+ It is recommended that, where possible, zone private keys and the
+ zone file master copy that is to be signed, be kept and used in off-
+ line, non-network connected, physically secure machines only.
+ Periodically an application can be run to add authentication to a
+ zone by adding RRSIG and NSEC RRs. Then the augmented file can be
+ transferred.
+
+ When relying on dynamic update to manage a signed zone [10], be aware
+ that at least one private key of the zone will have to reside on the
+ master server. This key is only as secure as the amount of exposure
+ the server receives to unknown clients and the security of the host.
+ Although not mandatory one could administer the DNS in the following
+ way. The master that processes the dynamic updates is unavailable
+ from generic hosts on the Internet, it is not listed in the NS RR
+ set, although its name appears in the SOA RRs MNAME field. The
+ nameservers in the NS RR set are able to receive zone updates through
+ NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism. This
+ approach is known as the "hidden master" setup.
+
+ The ideal situation is to have a one way information flow to the
+ network to avoid the possibility of tampering from the network.
+ Keeping the zone master file on-line on the network and simply
+ cycling it through an off-line signer does not do this. The on-line
+ version could still be tampered with if the host it resides on is
+ compromised. For maximum security, the master copy of the zone file
+ should be off net and should not be updated based on an unsecured
+ network mediated communication.
+
+ In general keeping a zone-file off-line will not be practical and the
+ machines on which zone files are maintained will be connected to a
+ network. Operators are advised to take security measures to shield
+ unauthorized access to the master copy.
+
+ For dynamically updated secured zones [10] both the master copy and
+ the private key that is used to update signatures on updated RRs will
+ need to be on-line.
+
+
+4. Signature generation, Key Rollover and Related Policies
+
+4.1. Time in DNSSEC
+
+ Without DNSSEC all times in DNS are relative. The SOA fields
+ REFRESH, RETRY and EXPIRATION are timers used to determine the time
+ elapsed after a slave server synchronized with a master server. The
+ Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 12]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ are used to determine how long a forwarder should cache data after it
+ has been fetched from an authoritative server. By using a signature
+ validity period, DNSSEC introduces the notion of an absolute time in
+ the DNS. Signatures in DNSSEC have an expiration date after which
+ the signature is marked as invalid and the signed data is to be
+ considered Bogus.
+
+4.1.1. Time Considerations
+
+ Because of the expiration of signatures, one should consider the
+ following:
+ o We suggest the Maximum Zone TTL of your zone data to be a fraction
+ of your signature validity period.
+ If the TTL would be of similar order as the signature validity
+ period, then all RRSets fetched during the validity period
+ would be cached until the signature expiration time. Section
+ 7.1 of [4] suggests that "the resolver may use the time
+ remaining before expiration of the signature validity period of
+ a signed RRSet as an upper bound for the TTL". As a result
+ query load on authoritative servers would peak at signature
+ expiration time, as this is also the time at which records
+ simultaneously expire from caches.
+ To avoid query load peaks we suggest the TTL on all the RRs in
+ your zone to be at least a few times smaller than your
+ signature validity period.
+ o We suggest the Signature Publication Period to end at least one
+ Maximum Zone TTL duration before the end of the Signature Validity
+ Period.
+ Re-signing a zone shortly before the end of the signature
+ validity period may cause simultaneous expiration of data from
+ caches. This in turn may lead to peaks in the load on
+ authoritative servers.
+ o We suggest the minimum zone TTL to be long enough to both fetch
+ and verify all the RRs in the trust chain. In workshop
+ environments it has been demonstrated [19] that a low TTL (under 5
+ to 10 minutes) caused disruptions because of the following two
+ problems:
+ 1. During validation, some data may expire before the
+ validation is complete. The validator should be able to keep
+ all data, until is completed. This applies to all RRs needed
+ to complete the chain of trust: DSs, DNSKEYs, RRSIGs, and the
+ final answers i.e. the RRSet that is returned for the initial
+ query.
+ 2. Frequent verification causes load on recursive nameservers.
+ Data at delegation points, DSs, DNSKEYs and RRSIGs benefit from
+ caching. The TTL on those should be relatively long.
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 13]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ o Slave servers will need to be able to fetch newly signed zones
+ well before the RRSIGs in the zone served by the slave server pass
+ their signature expiration time.
+ When a slave server is out of sync with its master and data in
+ a zone is signed by expired signatures it may be better for the
+ slave server not to give out any answer.
+ Normally a slave server that is not able to contact a master
+ server for an extended period will expire a zone. When that
+ happens the server will respond differently to queries for that
+ zone. Some servers issue SERVFAIL while others turn off the
+ 'AA' bit in the answers. The time of expiration is set in the
+ SOA record and is relative to the last successful refresh
+ between the master and the slave server. There exists no
+ coupling between the signature expiration of RRSIGs in the zone
+ and the expire parameter in the SOA.
+ If the server serves a DNSSEC zone then it may well happen that
+ the signatures expire well before the SOA expiration timer
+ counts down to zero. It is not possible to completely prevent
+ this from happening by tweaking the SOA parameters.
+ However, the effects can be minimized where the SOA expiration
+ time is equal or shorter than the signature validity period.
+ The consequence of an authoritative server not being able to
+ update a zone, whilst that zone includes expired signatures, is
+ that non-secure resolvers will continue to be able to resolve
+ data served by the particular slave servers while security
+ aware resolvers will experience problems because of answers
+ being marked as Bogus.
+ We suggest the SOA expiration timer being approximately one
+ third or one fourth of the signature validity period. It will
+ allow problems with transfers from the master server to be
+ noticed before the actual signature times out.
+ We also suggest that operators of nameservers that supply
+ secondary services develop 'watch dogs' to spot upcoming
+ signature expirations in zones they slave, and take appropriate
+ action.
+ When determining the value for the expiration parameter one has
+ to take the following into account: What are the chances that
+ all my secondaries expire the zone; How quickly can I reach an
+ administrator of secondary servers to load a valid zone? All
+ these arguments are not DNSSEC specific but may influence the
+ choice of your signature validity intervals.
+
+4.2. Key Rollovers
+
+ A DNSSEC key cannot be used forever (see Section 3.3). So key
+ rollovers -- or supercessions, as they are sometimes called -- are a
+ fact of life when using DNSSEC. Zone administrators who are in the
+ process of rolling their keys have to take into account that data
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 14]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ published in previous versions of their zone still lives in caches.
+ When deploying DNSSEC, this becomes an important consideration;
+ ignoring data that may be in caches may lead to loss of service for
+ clients.
+
+ The most pressing example of this occurs when zone material signed
+ with an old key is being validated by a resolver which does not have
+ the old zone key cached. If the old key is no longer present in the
+ current zone, this validation fails, marking the data Bogus.
+ Alternatively, an attempt could be made to validate data which is
+ signed with a new key against an old key that lives in a local cache,
+ also resulting in data being marked Bogus.
+
+4.2.1. Zone Signing Key Rollovers
+
+ For zone signing key rollovers there are two ways to make sure that
+ during the rollover data still cached can be verified with the new
+ key sets or newly generated signatures can be verified with the keys
+ still in caches. One schema, described in Section 4.2.1.2, uses
+ double signatures; the other uses key pre-publication
+ (Section 4.2.1.1). The pros, cons and recommendations are described
+ in Section 4.2.1.3.
+
+4.2.1.1. Pre-publish Key Rollover
+
+ This section shows how to perform a ZSK rollover without the need to
+ sign all the data in a zone twice - the so-called "pre-publish
+ rollover".This method has advantages in the case of a key compromise.
+ If the old key is compromised, the new key has already been
+ distributed in the DNS. The zone administrator is then able to
+ quickly switch to the new key and remove the compromised key from the
+ zone. Another major advantage is that the zone size does not double,
+ as is the case with the double signature ZSK rollover. A small
+ "HOWTO" for this kind of rollover can be found in Appendix B.
+
+ Pre-publish Key Rollover involves four stages as follows:
+
+ initial new DNSKEY new RRSIGs DNSKEY removal
+
+ SOA0 SOA1 SOA2 SOA3
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2) RRSIG11(SOA3)
+
+ DNSKEY1 DNSKEY1 DNSKEY1 DNSKEY1
+ DNSKEY10 DNSKEY10 DNSKEY10 DNSKEY11
+ DNSKEY11 DNSKEY11
+ RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY) RRSIG1 (DNSKEY)
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 15]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ initial: Initial version of the zone: DNSKEY 1 is the key signing
+ key. DNSKEY 10 is used to sign all the data of the zone, the zone
+ signing key.
+ new DNSKEY: DNSKEY 11 is introduced into the key set. Note that no
+ signatures are generated with this key yet, but this does not
+ secure against brute force attacks on the public key. The minimum
+ duration of this pre-roll phase is the time it takes for the data
+ to propagate to the authoritative servers plus TTL value of the
+ key set.
+ new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) DNSKEY 11 is
+ used to sign the data in the zone exclusively (i.e. all the
+ signatures from DNSKEY 10 are removed from the zone). DNSKEY 10
+ remains published in the key set. This way data that was loaded
+ into caches from version 1 of the zone can still be verified with
+ key sets fetched from version 2 of the zone.
+ The minimum time that the key set including DNSKEY 10 is to be
+ published is the time that it takes for zone data from the
+ previous version of the zone to expire from old caches i.e. the
+ time it takes for this zone to propagate to all authoritative
+ servers plus the Maximum Zone TTL value of any of the data in the
+ previous version of the zone.
+ DNSKEY removal: DNSKEY 10 is removed from the zone. The key set, now
+ only containing DNSKEY 1 and DNSKEY 11 is re-signed with the
+ DNSKEY 1.
+
+ The above scheme can be simplified by always publishing the "future"
+ key immediately after the rollover. The scheme would look as follows
+ (we show two rollovers); the future key is introduced in "new DNSKEY"
+ as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
+ (II)":
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 16]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ initial new RRSIGs new DNSKEY
+
+ SOA0 SOA1 SOA2
+ RRSIG10(SOA0) RRSIG11(SOA1) RRSIG11(SOA2)
+
+ DNSKEY1 DNSKEY1 DNSKEY1
+ DNSKEY10 DNSKEY10 DNSKEY11
+ DNSKEY11 DNSKEY11 DNSKEY12
+ RRSIG1(DNSKEY) RRSIG1 (DNSKEY) RRSIG1(DNSKEY)
+ RRSIG10(DNSKEY) RRSIG11(DNSKEY) RRSIG11(DNSKEY)
+
+
+ new RRSIGs (II) new DNSKEY (II)
+
+ SOA3 SOA4
+ RRSIG12(SOA3) RRSIG12(SOA4)
+
+ DNSKEY1 DNSKEY1
+ DNSKEY11 DNSKEY12
+ DNSKEY12 DNSKEY13
+ RRSIG1(DNSKEY) RRSIG1(DNSKEY)
+ RRSIG12(DNSKEY) RRSIG12(DNSKEY)
+
+
+ Pre-Publish Key Rollover, showing two rollovers.
+
+ Note that the key introduced in the "new DNSKEY" phase is not used
+ for production yet; the private key can thus be stored in a
+ physically secure manner and does not need to be 'fetched' every time
+ a zone needs to be signed.
+
+4.2.1.2. Double Signature Zone Signing Key Rollover
+
+ This section shows how to perform a ZSK key rollover using the double
+ zone data signature scheme, aptly named "double sig rollover".
+
+ During the "new DNSKEY" stage the new version of the zone file will
+ need to propagate to all authoritative servers and the data that
+ exists in (distant) caches will need to expire, requiring at least
+ the maximum Zone TTL.
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 17]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ Double Signature Zone Signing Key Rollover involves three stages as
+ follows:
+
+ initial new DNSKEY DNSKEY removal
+
+ SOA0 SOA1 SOA2
+ RRSIG10(SOA0) RRSIG10(SOA1) RRSIG11(SOA2)
+ RRSIG11(SOA1)
+
+ DNSKEY1 DNSKEY1 DNSKEY1
+ DNSKEY10 DNSKEY10 DNSKEY11
+ DNSKEY11
+ RRSIG1(DNSKEY) RRSIG1(DNSKEY) RRSIG1(DNSKEY)
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) RRSIG11(DNSKEY)
+ RRSIG11(DNSKEY)
+
+ initial: Initial Version of the zone: DNSKEY 1 is the key signing
+ key. DNSKEY 10 is used to sign all the data of the zone, the zone
+ signing key.
+ new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
+ introduced into the key set and all the data in the zone is signed
+ with DNSKEY 10 and DNSKEY 11. The rollover period will need to
+ continue until all data from version 0 of the zone has expired
+ from remote caches. This will take at least the maximum Zone TTL
+ of version 0 of the zone.
+ DNSKEY removal: DNSKEY 10 is removed from the zone. All the
+ signatures from DNSKEY 10 are removed from the zone. The key set,
+ now only containing DNSKEY 11, is re-signed with DNSKEY 1.
+
+ At every instance, RRSIGs from the previous version of the zone can
+ be verified with the DNSKEY RRSet from the current version and the
+ other way around. The data from the current version can be verified
+ with the data from the previous version of the zone. The duration of
+ the "new DNSKEY" phase and the period between rollovers should be at
+ least the Maximum Zone TTL.
+
+ Making sure that the "new DNSKEY" phase lasts until the signature
+ expiration time of the data in initial version of the zone is
+ recommended. This way all caches are cleared of the old signatures.
+ However, this duration could be considerably longer than the Maximum
+ Zone TTL, making the rollover a lengthy procedure.
+
+ Note that in this example we assumed that the zone was not modified
+ during the rollover. New data can be introduced in the zone as long
+ as it is signed with both keys.
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 18]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+4.2.1.3. Pros and Cons of the Schemes
+
+ Pre-publish Key Rollover: This rollover does not involve signing the
+ zone data twice. Instead, before the actual rollover, the new key
+ is published in the key set and thus available for cryptanalysis
+ attacks. A small disadvantage is that this process requires four
+ steps. Also the pre-publish scheme involves more parental work
+ when used for KSK rollovers as explained in Section 4.2.3.
+ Double Signature Zone-signing Key Rollover: The drawback of this
+ signing scheme is that during the rollover the number of
+ signatures in your zone doubles, this may be prohibitive if you
+ have very big zones. An advantage is that it only requires three
+ steps.
+
+4.2.2. Key Signing Key Rollovers
+
+ For the rollover of a key signing key the same considerations as for
+ the rollover of a zone signing key apply. However we can use a
+ double signature scheme to guarantee that old data (only the apex key
+ set) in caches can be verified with a new key set and vice versa.
+ Since only the key set is signed with a KSK, zone size considerations
+ do not apply.
+
+
+ initial new DNSKEY DS change DNSKEY removal
+ Parent:
+ SOA0 --------> SOA1 -------->
+ RRSIGpar(SOA0) --------> RRSIGpar(SOA1) -------->
+ DS1 --------> DS2 -------->
+ RRSIGpar(DS) --------> RRSIGpar(DS) -------->
+
+
+ Child:
+ SOA0 SOA1 --------> SOA2
+ RRSIG10(SOA0) RRSIG10(SOA1) --------> RRSIG10(SOA2)
+ -------->
+ DNSKEY1 DNSKEY1 --------> DNSKEY2
+ DNSKEY2 -------->
+ DNSKEY10 DNSKEY10 --------> DNSKEY10
+ RRSIG1 (DNSKEY) RRSIG1 (DNSKEY) --------> RRSIG2 (DNSKEY)
+ RRSIG2 (DNSKEY) -------->
+ RRSIG10(DNSKEY) RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY)
+
+ Stages of Deployment for Key Signing Key Rollover.
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 19]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ initial: Initial version of the zone. The parental DS points to
+ DNSKEY1. Before the rollover starts the child will have to verify
+ what the TTL is of the DS RR that points to DNSKEY1 - it is needed
+ during the rollover and we refer to the value as TTL_DS.
+ new DNSKEY: During the "new DNSKEY" phase the zone administrator
+ generates a second KSK, DNSKEY2. The key is provided to the
+ parent and the child will have to wait until a new DS RR has been
+ generated that points to DNSKEY2. After that DS RR has been
+ published on all servers authoritative for the parent's zone, the
+ zone administrator has to wait at least TTL_DS to make sure that
+ the old DS RR has expired from caches.
+ DS change: The parent replaces DS1 with DS2.
+ DNSKEY removal: DNSKEY1 has been removed.
+
+ The scenario above puts the responsibility for maintaining a valid
+ chain of trust with the child. It also is based on the premises that
+ the parent only has one DS RR (per algorithm) per zone. An
+ alternative mechanism has been considered. Using an established
+ trust relation, the interaction can be performed in-band, and the
+ removal of the keys by the child can possibly be signaled by the
+ parent. In this mechanism there are periods where there are two DS
+ RRs at the parent. Since at the moment of writing the protocol for
+ this interaction has not been developed, further discussion is out of
+ scope for this document.
+
+4.2.3. Difference Between ZSK and KSK Rollovers
+
+ Note that KSK rollovers and ZSK rollovers are different in the sense
+ that a KSK rollover requires interaction with the parent (and
+ possibly replacing of trust anchors) and the ensuing delay while
+ waiting for it.
+
+ A zone key rollover can be handled in two different ways: pre-publish
+ (Section Section 4.2.1.1) and double signature (Section
+ Section 4.2.1.2).
+
+ As the KSK is used to validate the key set and because the KSK is not
+ changed during a ZSK rollover, a cache is able to validate the new
+ key set of the zone. The pre-publish method would also work for a
+ KSK rollover. The records that are to be pre-published are the
+ parental DS RRs. The pre-publish method has some drawbacks for KSKs.
+ We first describe the rollover scheme and then indicate these
+ drawbacks.
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 20]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ initial new DS new DNSKEY DS/DNSKEY removal
+ Parent:
+ SOA0 SOA1 --------> SOA2
+ RRSIGpar(SOA0) RRSIGpar(SOA1) --------> RRSIGpar(SOA2)
+ DS1 DS1 --------> DS2
+ DS2 -------->
+ RRSIGpar(DS) RRSIGpar(DS) --------> RRSIGpar(DS)
+
+
+
+ Child:
+ SOA0 --------> SOA1 SOA1
+ RRSIG10(SOA0) --------> RRSIG10(SOA1) RRSIG10(SOA1)
+ -------->
+ DNSKEY1 --------> DNSKEY2 DNSKEY2
+ -------->
+ DNSKEY10 --------> DNSKEY10 DNSKEY10
+ RRSIG1 (DNSKEY) --------> RRSIG2(DNSKEY) RRSIG2 (DNSKEY)
+ RRSIG10(DNSKEY) --------> RRSIG10(DNSKEY) RRSIG10(DNSKEY)
+
+ Stages of Deployment for a Pre-publish Key Signing Key rollover.
+
+ When the child zone wants to roll it notifies the parent during the
+ "new DS" phase and submits the new key (or the corresponding DS) to
+ the parent. The parent publishes DS1 and DS2, pointing to DNSKEY1
+ and DNSKEY2 respectively. During the rollover ("new DNSKEY" phase),
+ which can take place as soon as the new DS set propagated through the
+ DNS, the child replaces DNSKEY1 with DNSKEY2. Immediately after that
+ ("DS/DNSKEY removal" phase) it can notify the parent that the old DS
+ record can be deleted.
+
+ The drawbacks of this scheme are that during the "new DS" phase the
+ parent cannot verify the match between the DS2 RR and DNSKEY2 using
+ the DNS -- as DNSKEY2 is not yet published. Besides, we introduce a
+ "security lame" key (See Section 4.4.3). Finally the child-parent
+ interaction consists of two steps. The "double signature" method
+ only needs one interaction.
+
+4.2.4. Automated Key Rollovers
+
+ As keys must be renewed periodically, there is some motivation to
+ automate the rollover process. Consider that:
+
+ o ZSK rollovers are easy to automate as only the child zone is
+ involved.
+ o A KSK rollover needs interaction between parent and child. Data
+ exchange is needed to provide the new keys to the parent,
+ consequently, this data must be authenticated and integrity must
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 21]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ be guaranteed in order to avoid attacks on the rollover.
+
+4.3. Planning for Emergency Key Rollover
+
+ This section deals with preparation for a possible key compromise.
+ Our advice is to have a documented procedure ready for when a key
+ compromise is suspected or confirmed.
+
+ When the private material of one of your keys is compromised it can
+ be used for as long as a valid trust chain exists. A trust chain
+ remains intact for:
+ o as long as a signature over the compromised key in the trust chain
+ is valid,
+ o as long as a parental DS RR (and signature) points to the
+ compromised key,
+ o as long as the key is anchored in a resolver and is used as a
+ starting point for validation (this is generally the hardest to
+ update).
+
+ While a trust chain to your compromised key exists, your name-space
+ is vulnerable to abuse by anyone who has obtained illegitimate
+ possession of the key. Zone operators have to make a trade off if
+ the abuse of the compromised key is worse than having data in caches
+ that cannot be validated. If the zone operator chooses to break the
+ trust chain to the compromised key, data in caches signed with this
+ key cannot be validated. However, if the zone administrator chooses
+ to take the path of a regular roll-over, the malicious key holder can
+ spoof data so that it appears to be valid.
+
+4.3.1. KSK Compromise
+
+ A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
+ as long as the compromised KSK is configured as trust anchor or a
+ parental DS points to it.
+
+ A compromised KSK can be used to sign the key set of an attacker's
+ zone. That zone could be used to poison the DNS.
+
+ Therefore when the KSK has been compromised, the trust anchor or the
+ parental DS, should be replaced as soon as possible. It is local
+ policy whether to break the trust chain during the emergency
+ rollover. The trust chain would be broken when the compromised KSK
+ is removed from the child's zone while the parent still has a DS
+ pointing to the compromised KSK (the assumption is that there is only
+ one DS at the parent. If there are multiple DSs this does not apply
+ -- however the chain of trust of this particular key is broken).
+
+ Note that an attacker's zone still uses the compromised KSK and the
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 22]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ presence of a parental DS would cause the data in this zone to appear
+ as valid. Removing the compromised key would cause the attacker's
+ zone to appear as valid and the child's zone as Bogus. Therefore we
+ advise not to remove the KSK before the parent has a DS to a new KSK
+ in place.
+
+4.3.1.1. Keeping the Chain of Trust Intact
+
+ If we follow this advice the timing of the replacement of the KSK is
+ somewhat critical. The goal is to remove the compromised KSK as soon
+ as the new DS RR is available at the parent. And also make sure that
+ the signature made with a new KSK over the key set with the
+ compromised KSK in it expires just after the new DS appears at the
+ parent. Thus removing the old cruft in one swoop.
+
+ The procedure is as follows:
+ 1. Introduce a new KSK into the key set, keep the compromised KSK in
+ the key set.
+ 2. Sign the key set, with a short validity period. The validity
+ period should expire shortly after the DS is expected to appear
+ in the parent and the old DSs have expired from caches.
+ 3. Upload the DS for this new key to the parent.
+ 4. Follow the procedure of the regular KSK rollover: Wait for the DS
+ to appear in the authoritative servers and then wait as long as
+ the TTL of the old DS RRs. If necessary re-sign the DNSKEY RRSet
+ and modify/extend the expiration time.
+ 5. Remove the compromised DNSKEY RR from the zone and re-sign the
+ key set using your "normal" validity interval.
+
+ An additional danger of a key compromise is that the compromised key
+ could be used to facilitate a legitimate DNSKEY/DS rollover and/or
+ nameserver changes at the parent. When that happens the domain may
+ be in dispute. An authenticated out-of-band and secure notify
+ mechanism to contact a parent is needed in this case.
+
+ Note that this is only a problem when the DNSKEY and or DS records
+ are used for authentication at the parent.
+
+4.3.1.2. Breaking the Chain of Trust
+
+ There are two methods to break the chain of trust. The first method
+ causes the child zone to appear as 'Bogus' to validating resolvers.
+ The other causes the the child zone to appear as 'insecure'. These
+ are described below.
+
+ In the method that causes the child zone to appear as 'Bogus' to
+ validating resolvers, the child zone replaces the current KSK with a
+ new one and resigns the key set. Next it sends the DS of the new key
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 23]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ to the parent. Only after the parent has placed the new DS in the
+ zone, the child's chain of trust is repaired.
+
+ An alternative method of breaking the chain of trust is by removing
+ the DS RRs from the parent zone altogether. As a result the child
+ zone would become insecure.
+
+4.3.2. ZSK Compromise
+
+ Primarily because there is no parental interaction required when a
+ ZSK is compromised, the situation is less severe than with a KSK
+ compromise. The zone must still be re-signed with a new ZSK as soon
+ as possible. As this is a local operation and requires no
+ communication between the parent and child this can be achieved
+ fairly quickly. However, one has to take into account that just as
+ with a normal rollover the immediate disappearance of the old
+ compromised key may lead to verification problems. Also note that as
+ long as the RRSIG over the compromised ZSK is not expired the zone
+ may be still at risk.
+
+4.3.3. Compromises of Keys Anchored in Resolvers
+
+ A key can also be pre-configured in resolvers. For instance, if
+ DNSSEC is successfully deployed the root key may be pre-configured in
+ most security aware resolvers.
+
+ If trust-anchor keys are compromised, the resolvers using these keys
+ should be notified of this fact. Zone administrators may consider
+ setting up a mailing list to communicate the fact that a SEP key is
+ about to be rolled over. This communication will of course need to
+ be authenticated e.g. by using digital signatures.
+
+ End-users faced with the task of updating an anchored key should
+ always validate the new key. New keys should be authenticated out-
+ of-band, for example, looking them up on an SSL secured announcement
+ website.
+
+4.4. Parental Policies
+
+4.4.1. Initial Key Exchanges and Parental Policies Considerations
+
+ The initial key exchange is always subject to the policies set by the
+ parent. When designing a key exchange policy one should take into
+ account that the authentication and authorization mechanisms used
+ during a key exchange should be as strong as the authentication and
+ authorization mechanisms used for the exchange of delegation
+ information between parent and child. I.e. there is no implicit need
+ in DNSSEC to make the authentication process stronger than it was in
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 24]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ DNS.
+
+ Using the DNS itself as the source for the actual DNSKEY material,
+ with an out-of-band check on the validity of the DNSKEY, has the
+ benefit that it reduces the chances of user error. A DNSKEY query
+ tool can make use of the SEP bit [3] to select the proper key from a
+ DNSSEC key set; thereby reducing the chance that the wrong DNSKEY is
+ sent. It can validate the self-signature over a key; thereby
+ verifying the ownership of the private key material. Fetching the
+ DNSKEY from the DNS ensures that the chain of trust remains intact
+ once the parent publishes the DS RR indicating the child is secure.
+
+ Note: the out-of-band verification is still needed when the key-
+ material is fetched via the DNS. The parent can never be sure
+ whether the DNSKEY RRs have been spoofed or not.
+
+4.4.2. Storing Keys or Hashes?
+
+ When designing a registry system one should consider which of the
+ DNSKEYs and/or the corresponding DSs to store. Since a child zone
+ might wish to have a DS published using a message digest algorithm
+ not yet understood by the registry, the registry can't count on being
+ able to generate the DS record from a raw DNSKEY. Thus, we recommend
+ that registry systems at least support storing DS records.
+
+ It may also be useful to store DNSKEYs, since having them may help
+ during troubleshooting and, as long as the child's chosen message
+ digest is supported, the overhead of generating DS records from them
+ is minimal. Having an out-of-band mechanism, such as a registry
+ directory (e.g. Whois), to find out which keys are used to generate
+ DS Resource Records for specific owners and/or zones may also help
+ with troubleshooting.
+
+ The storage considerations also relate to the design of the customer
+ interface and the method by which data is transferred between
+ registrant and registry; Will the child zone administrator be able to
+ upload DS RRs with unknown hash algorithms or does the interface only
+ allow DNSKEYs? In the registry-registrar model one can use the
+ DNSSEC EPP protocol extension [16] which allows transfer of DS RRs
+ and optionally DNSKEY RRs.
+
+4.4.3. Security Lameness
+
+ Security Lameness is defined as what happens when a parent has a DS
+ RR pointing to a non-existing DNSKEY RR. When this happens the
+ child's zone may be marked as "Bogus" by verifying DNS clients.
+
+ As part of a comprehensive delegation check the parent could, at key
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 25]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ exchange time, verify that the child's key is actually configured in
+ the DNS. However if a parent does not understand the hashing
+ algorithm used by child the parental checks are limited to only
+ comparing the key id.
+
+ Child zones should be very careful removing DNSKEY material,
+ specifically SEP keys, for which a DS RR exists.
+
+ Once a zone is "security lame", a fix (e.g. removing a DS RR) will
+ take time to propagate through the DNS.
+
+4.4.4. DS Signature Validity Period
+
+ Since the DS can be replayed as long as it has a valid signature, a
+ short signature validity period over the DS minimizes the time a
+ child is vulnerable in the case of a compromise of the child's
+ KSK(s). A signature validity period that is too short introduces the
+ possibility that a zone is marked Bogus in case of a configuration
+ error in the signer. There may not be enough time to fix the
+ problems before signatures expire. Something as mundane as operator
+ unavailability during weekends shows the need for DS signature
+ validity periods longer than 2 days. We recommend an absolute
+ minimum for a DS signature validity period of a few days.
+
+ The maximum signature validity period of the DS record depends on how
+ long child zones are willing to be vulnerable after a key compromise.
+ On the other hand shortening the DS signature validity interval
+ increases the operational risk for the parent. Therefore the parent
+ may have policy to use a signature validity interval that is
+ considerably longer than the child would hope for.
+
+ A compromise between the operational constraints of the parent and
+ minimizing damage for the child may result in a DS signature validity
+ period somewhere between the order of a week to order of months.
+
+ In addition to the signature validity period, which sets a lower
+ bound on the number of times the zone owner will need to sign the
+ zone data and which sets an upper bound to the time a child is
+ vulnerable after key compromise, there is the TTL value on the DS
+ RRs. Shortening the TTL means that the authoritative servers will
+ see more queries. But on the other hand, a short TTL lowers the
+ persistence of DS RRSets in caches thereby increases the speed with
+ which updated DS RRSets propagate through the DNS.
+
+
+5. IANA Considerations
+
+ This overview document introduces no new IANA considerations.
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 26]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+6. Security Considerations
+
+ DNSSEC adds data integrity to the DNS. This document tries to assess
+ the operational considerations to maintain a stable and secure DNSSEC
+ service. Not taking into account the 'data propagation' properties
+ in the DNS will cause validation failures and may make secured zones
+ unavailable to security aware resolvers.
+
+
+7. Acknowledgments
+
+ Most of the ideas in this draft were the result of collective efforts
+ during workshops, discussions and try outs.
+
+ At the risk of forgetting individuals who were the original
+ contributors of the ideas we would like to acknowledge people who
+ were actively involved in the compilation of this document. In
+ random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
+ Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
+ Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
+ Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch.
+
+ Some material in this document has been copied from RFC 2541 [12].
+
+ Mike StJohns designed the key exchange between parent and child
+ mentioned in the last paragraph of Section 4.2.2
+
+ Section 4.2.4 was supplied by G. Guette and O. Courtay.
+
+ Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
+ the spelling and style issues.
+
+ Kolkman and Gieben take the blame for introducing all miscakes(SIC).
+
+ Kolkman was employed by the RIPE NCC while working on this document.
+
+
+8. References
+
+8.1. Normative References
+
+ [1] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [2] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [3] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 27]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+ RFC 3757, May 2004.
+
+ [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+ [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Resource Records for the DNS Security Extensions", RFC 4034,
+ March 2005.
+
+ [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ RFC 4035, March 2005.
+
+8.2. Informative References
+
+ [7] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+ August 1996.
+
+ [8] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
+ (DNS NOTIFY)", RFC 1996, August 1996.
+
+ [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [10] Eastlake, D., "Secure Domain Name System Dynamic Update",
+ RFC 2137, April 1997.
+
+ [11] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+ RFC 2308, March 1998.
+
+ [12] Eastlake, D., "DNS Security Operational Considerations",
+ RFC 2541, March 1999.
+
+ [13] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+ RFC 3658, December 2003.
+
+ [14] Orman, H. and P. Hoffman, "Determining Strengths For Public
+ Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
+ April 2004.
+
+ [15] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+ [16] Hollenbeck, S., "Domain Name System (DNS) Security Extensions
+ Mapping for the Extensible Provisioning Protocol (EPP)",
+ RFC 4310, December 2005.
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 28]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ [17] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
+ Sizes", The Journal of Cryptology 14 (255-293), 2001.
+
+ [18] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
+ Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
+ (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
+ 1996.
+
+ [19] Rose, S., "NIST DNSSEC workshop notes", June 2001.
+
+ [20] Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
+ Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt
+ (work in progress), January 2006.
+
+ [21] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+ Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt
+ (work in progress), January 2006.
+
+
+Appendix A. Terminology
+
+ In this document there is some jargon used that is defined in other
+ documents. In most cases we have not copied the text from the
+ documents defining the terms but given a more elaborate explanation
+ of the meaning. Note that these explanations should not be seen as
+ authoritative.
+
+ Anchored Key: A DNSKEY configured in resolvers around the globe.
+ This key is hard to update, hence the term anchored.
+ Bogus: Also see Section 5 of [4]. An RRSet in DNSSEC is marked
+ "Bogus" when a signature of a RRSet does not validate against a
+ DNSKEY.
+ Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
+ exclusively for signing the apex key set. The fact that a key is
+ a KSK is only relevant to the signing tool.
+ Key size: The term 'key size' can be substituted by 'modulus size'
+ throughout the document. It is mathematically more correct to use
+ modulus size, but as this is a document directed at operators we
+ feel more at ease with the term key size.
+ Private and Public Keys: DNSSEC secures the DNS through the use of
+ public key cryptography. Public key cryptography is based on the
+ existence of two (mathematically related) keys, a public key and a
+ private key. The public keys are published in the DNS by use of
+ the DNSKEY Resource Record (DNSKEY RR). Private keys should
+ remain private.
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 29]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ Key Rollover: A key rollover (also called key supercession in some
+ environments) is the act of replacing one key pair by another at
+ the end of a key effectivity period.
+ Secure Entry Point key or SEP Key: A KSK that has a parental DS
+ record pointing to it or is configured as a trust anchor.
+ Although not required by the protocol we recommend that the SEP
+ flag [3] is set on these keys.
+ Self-signature: This is only applies to signatures over DNSKEYs; a
+ signature made with DNSKEY x, over DNSKEY x is called a self-
+ signature. Note: without further information self-signatures
+ convey no trust, they are useful to check the authenticity of the
+ DNSKEY, i.e. they can be used as a hash.
+ Singing the Zone File: The term used for the event where an
+ administrator joyfully signs its zone file while producing melodic
+ sound patterns.
+ Signer: The system that has access to the private key material and
+ signs the Resource Record sets in a zone. A signer may be
+ configured to sign only parts of the zone e.g. only those RRSets
+ for which existing signatures are about to expire.
+ Zone Signing Key or ZSK: A Zone Signing Key (ZSK) is a key that is
+ used for signing all data in a zone. The fact that a key is a ZSK
+ is only relevant to the signing tool.
+ Zone Administrator: The 'role' that is responsible for signing a zone
+ and publishing it on the primary authoritative server.
+
+
+Appendix B. Zone Signing Key Rollover Howto
+
+ Using the pre-published signature scheme and the most conservative
+ method to assure oneself that data does not live in caches, here
+ follows the "HOWTO".
+ Step 0: The preparation: Create two keys and publish both in your key
+ set. Mark one of the keys as "active" and the other as
+ "published". Use the "active" key for signing your zone data.
+ Store the private part of the "published" key, preferably off-
+ line.
+ The protocol does not provide for attributes to mark a key as
+ active or published. This is something you have to do on your
+ own, through the use of a notebook or key management tool.
+ Step 1: Determine expiration: At the beginning of the rollover make a
+ note of the highest expiration time of signatures in your zone
+ file created with the current key marked as "active".
+ Wait until the expiration time marked in Step 1 has passed
+ Step 2: Then start using the key that was marked as "published" to
+ sign your data i.e. mark it as "active". Stop using the key that
+ was marked as "active", mark it as "rolled".
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 30]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ Step 3: It is safe to engage in a new rollover (Step 1) after at
+ least one "signature validity period".
+
+
+Appendix C. Typographic Conventions
+
+ The following typographic conventions are used in this document:
+ Key notation: A key is denoted by DNSKEYx, where x is a number or an
+ identifier, x could be thought of as the key id.
+ RRSet notations: RRs are only denoted by the type. All other
+ information - owner, class, rdata and TTL - is left out. Thus:
+ "example.com 3600 IN A 192.0.2.1" is reduced to "A". RRSets are a
+ list of RRs. A example of this would be: "A1, A2", specifying the
+ RRSet containing two "A" records. This could again be abbreviated
+ to just "A".
+ Signature notation: Signatures are denoted as RRSIGx(RRSet), which
+ means that RRSet is signed with DNSKEYx.
+ Zone representation: Using the above notation we have simplified the
+ representation of a signed zone by leaving out all unnecessary
+ details such as the names and by representing all data by "SOAx"
+ SOA representation: SOAs are represented as SOAx, where x is the
+ serial number.
+ Using this notation the following signed zone:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 31]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ example.net. 86400 IN SOA ns.example.net. bert.example.net. (
+ 2006022100 ; serial
+ 86400 ; refresh ( 24 hours)
+ 7200 ; retry ( 2 hours)
+ 3600000 ; expire (1000 hours)
+ 28800 ) ; minimum ( 8 hours)
+ 86400 RRSIG SOA 5 2 86400 20130522213204 (
+ 20130422213204 14 example.net.
+ cmL62SI6iAX46xGNQAdQ... )
+ 86400 NS a.iana-servers.net.
+ 86400 NS b.iana-servers.net.
+ 86400 RRSIG NS 5 2 86400 20130507213204 (
+ 20130407213204 14 example.net.
+ SO5epiJei19AjXoUpFnQ ... )
+ 86400 DNSKEY 256 3 5 (
+ EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
+ 86400 DNSKEY 257 3 5 (
+ gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
+ 86400 RRSIG DNSKEY 5 2 86400 20130522213204 (
+ 20130422213204 14 example.net.
+ J4zCe8QX4tXVGjV4e1r9... )
+ 86400 RRSIG DNSKEY 5 2 86400 20130522213204 (
+ 20130422213204 15 example.net.
+ keVDCOpsSeDReyV6O... )
+ 86400 RRSIG NSEC 5 2 86400 20130507213204 (
+ 20130407213204 14 example.net.
+ obj3HEp1GjnmhRjX... )
+ a.example.net. 86400 IN TXT "A label"
+ 86400 RRSIG TXT 5 3 86400 20130507213204 (
+ 20130407213204 14 example.net.
+ IkDMlRdYLmXH7QJnuF3v... )
+ 86400 NSEC b.example.com. TXT RRSIG NSEC
+ 86400 RRSIG NSEC 5 3 86400 20130507213204 (
+ 20130407213204 14 example.net.
+ bZMjoZ3bHjnEz0nIsPMM... )
+ ...
+
+ is reduced to the following representation:
+
+ SOA2006022100
+ RRSIG14(SOA2006022100)
+ DNSKEY14
+ DNSKEY15
+
+ RRSIG14(KEY)
+ RRSIG15(KEY)
+
+ The rest of the zone data has the same signature as the SOA record,
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 32]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ i.e a RRSIG created with DNSKEY 14.
+
+
+Appendix D. Document Details and Changes
+
+ This section is to be removed by the RFC editor if and when the
+ document is published.
+
+ $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14
+ 2005/03/21 15:51:41 dnssec Exp $
+
+D.1. draft-ietf-dnsop-dnssec-operational-practices-00
+
+ Submission as working group document. This document is a modified
+ and updated version of draft-kolkman-dnssec-operational-practices-00.
+
+D.2. draft-ietf-dnsop-dnssec-operational-practices-01
+
+ changed the definition of "Bogus" to reflect the one in the protocol
+ draft.
+
+ Bad to Bogus
+
+ Style and spelling corrections
+
+ KSK - SEP mapping made explicit.
+
+ Updates from Sam Weiler added
+
+D.3. draft-ietf-dnsop-dnssec-operational-practices-02
+
+ Style and errors corrected.
+
+ Added Automatic rollover requirements from I-D.ietf-dnsop-key-
+ rollover-requirements.
+
+D.4. draft-ietf-dnsop-dnssec-operational-practices-03
+
+ Added the definition of Key effectivity period and used that term
+ instead of Key validity period.
+
+ Modified the order of the sections, based on a suggestion by Rip
+ Loomis.
+
+ Included parts from RFC 2541 [12]. Most of its ground was already
+ covered. This document obsoletes RFC 2541 [12]. Section 3.1.2
+ deserves some review as it in contrast to RFC 2541 does _not_ give
+ recomendations about root-zone keys.
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 33]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+ added a paragraph to Section 4.4.4
+
+D.5. draft-ietf-dnsop-dnssec-operational-practices-04
+
+ Somewhat more details added about the pre-publish KSK rollover. Also
+ moved that subsection down a bit.
+
+ Editorial and content nits that came in during wg last call were
+ fixed.
+
+D.6. draft-ietf-dnsop-dnssec-operational-practices-05
+
+ Applied some another set of comments that came in _after_ the the
+ WGLC.
+
+ Applied comments from Hilarie Orman and made a referece to RFC 3766.
+ Deleted of a lot of key length discussion and took over the
+ recommendations from RFC 3766.
+
+ Reworked all the heading of the rollover figures
+
+D.7. draft-ietf-dnsop-dnssec-operational-practices-06
+
+ One comment from Scott Rose applied.
+
+ Marcos Sanz gave a lots of editorial nits. Almost all are
+ incorporated.
+
+D.8. draft-ietf-dnsop-dnssec-operational-practices-07
+
+ Peter Koch's comments applied.
+
+ SHA-1/SHA-256 remarks added
+
+D.9. draft-ietf-dnsop-dnssec-operational-practices-08
+
+ IESG comments applied. Added headers and some captions to the tables
+ and applied all the nits.
+
+ IESG DISCUSS comments applied
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 34]
+
+Internet-Draft DNSSEC Operational Practices March 2006
+
+
+Authors' Addresses
+
+ Olaf M. Kolkman
+ NLnet Labs
+ Kruislaan 419
+ Amsterdam 1098 VA
+ The Netherlands
+
+ Email: olaf@nlnetlabs.nl
+ URI: http://www.nlnetlabs.nl
+
+
+ Miek Gieben
+ NLnet Labs
+ Kruislaan 419
+ Amsterdam 1098 VA
+ The Netherlands
+
+ Email: miek@nlnetlabs.nl
+ URI: http://www.nlnetlabs.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 35]
+
+Internet-Draft DNSSEC Operational Practices March 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.
+
+
+
+
+Kolkman & Gieben Expires September 7, 2006 [Page 36]
+
diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
new file mode 100644
index 0000000..bcd0d14
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
@@ -0,0 +1,396 @@
+
+
+
+
+
+
+INTERNET-DRAFT D. Senie
+Category: BCP Amaranth Networks Inc.
+Expires in six months July 2005
+
+ Encouraging the use of DNS IN-ADDR Mapping
+ draft-ietf-dnsop-inaddr-required-07.txt
+
+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
+
+Abstract
+
+ Mapping of addresses to names has been a feature of DNS. Many sites,
+ implement it, many others don't. Some applications attempt to use it
+ as a part of a security strategy. The goal of this document is to
+ encourage proper deployment of address to name mappings, and provide
+ guidance for their use.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society. (2005)
+
+1. Introduction
+
+ The Domain Name Service has provision for providing mapping of IP
+ addresses to host names. It is common practice to ensure both name to
+ address, and address to name mappings are provided for networks. This
+ practice, while documented, has never been required, though it is
+ generally encouraged. This document both encourages the presence of
+
+
+
+Senie [Page 1]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ these mappings and discourages reliance on such mappings for security
+ checks.
+
+ 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. Discussion
+
+
+ From the early days of the Domain Name Service [RFC883] a special
+ domain has been set aside for resolving mappings of IP addresses to
+ domain names. This was refined in [RFC1035], describing the .IN-
+ ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA
+ was added [RFC3152]. This document uses IPv4 CIDR block sizes and
+ allocation strategy where there are differences and uses IPv4
+ terminology. Aside from these differences, this document can and
+ should be applied to both address spaces.
+
+ The assignment of blocks of IP address space was delegated to three
+ regional registries. Guidelines for the registries are specified in
+ [RFC2050], which requires regional registries to maintain IN-ADDR
+ records on the large blocks of space issued to ISPs and others.
+
+ ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
+ allocations. For smaller allocations, ARIN can provide IN-ADDR for
+ /24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to
+ update IN-ADDR, however the present version of its policy document
+ for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
+ copies of this document. As of this writing, it appears APNIC has no
+ actual policy on IN-ADDR. RIPE appears to have the strongest policy
+ in this area [RIPE302] indicating Local Internet Registries should
+ provide IN-ADDR services, and delegate those as appropriate when
+ address blocks are delegated.
+
+ As we can see, the regional registries have their own policies for
+ recommendations and/or requirements for IN-ADDR maintenance. It
+ should be noted, however, that many address blocks were allocated
+ before the creation of the regional registries, and thus it is
+ unclear whether any of the policies of the registries are binding on
+ those who hold blocks from that era.
+
+ Registries allocate address blocks on CIDR [RFC1519] boundaries.
+ Unfortunately the IN-ADDR zones are based on classful allocations.
+ Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
+ exist, but are not always implemented.
+
+3. Examples of impact of missing IN-ADDR
+
+
+
+Senie [Page 2]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ These are some examples of problems that may be introduced by
+ reliance on IN-ADDR.
+
+ Some applications use DNS lookups for security checks. To ensure
+ validity of claimed names, some applications will look up IN-ADDR
+ records to get names, and then look up the resultant name to see if
+ it maps back to the address originally known. Failure to resolve
+ matching names is seen as a potential security concern.
+
+ Some FTP sites will flat-out reject users, even for anonymous FTP, if
+ the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
+ itself resolved, does not match. Some Telnet servers also implement
+ this check.
+
+ Web sites are in some cases using IN-ADDR checks to verify whether
+ the client is located within a certain geopolitical entity. This
+ approach has been employed for downloads of crypto software, for
+ example, where export of that software is prohibited to some locales.
+ Credit card anti-fraud systems also use these methods for geographic
+ placement purposes.
+
+ The popular TCP Wrappers program found on most Unix and Linux systems
+ has options to enforce IN-ADDR checks and to reject any client that
+ does not resolve. This program also has a way to check to see that
+ the name given by a PTR record then resolves back to the same IP
+ address. This method provdes more comfort but no appreciable
+ additional security.
+
+ Some anti-spam (anti junk email) systems use IN-ADDR to verify the
+ presence of a PTR record, or validate the PTR value points back to
+ the same address.
+
+ Many web servers look up the IN-ADDR of visitors to be used in log
+ analysis. This adds to the server load, but in the case of IN-ADDR
+ unavailability, it can lead to delayed responses for users.
+
+ Traceroutes with descriptive IN-ADDR naming proves useful when
+ debugging problems spanning large areas. When this information is
+ missing, the traceroutes take longer, and it takes additional steps
+ to determine that network is the cause of problems.
+
+ Wider-scale implementation of IN-ADDR on dialup, wireless access and
+ other such client-oriented portions of the Internet would result in
+ lower latency for queries (due to lack of negative caching), and
+ lower name server load and DNS traffic.
+
+4. Recommendations
+
+
+
+
+Senie [Page 3]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ 4.1 Delegation Recommendations
+
+
+ Regional Registries and any Local Registries to whom they delegate
+ should establish and convey a policy to those to whom they delegate
+ blocks that IN-ADDR mappings are recommended. Policies should
+ recommend those receiving delegations to provide IN-ADDR service
+ and/or delegate to downstream customers.
+
+ Network operators should define and implement policies and procedures
+ which delegate IN-ADDR to their clients who wish to run their own IN-
+ ADDR DNS services, and provide IN-ADDR services for those who do not
+ have the resources to do it themselves. Delegation mechanisms should
+ permit the downstream customer to implement and comply with IETF
+ recommendations application of IN-ADDR to CIDR [RFC2317].
+
+ All IP address space assigned and in use should be resolved by IN-
+ ADDR records. All PTR records must use canonical names.
+
+ All IP addresses in use within a block should have an IN-ADDR
+ mapping. Those addresses not in use, and those that are not valid for
+ use (zeros or ones broadcast addresses within a CIDR block) need not
+ have mappings.
+
+ It should be noted that due to CIDR, many addresses that appear to be
+ otherwise valid host addresses may actually be zeroes or ones
+ broadcast addresses. As such, attempting to audit a site's degree of
+ compliance may only be done with knowledge of the internal subnet
+ architecture of the site. It can be assumed, however, any host that
+ originates an IP packet necessarily will have a valid host address,
+ and must therefore have an IN-ADDR mapping.
+
+4.2 Application Recommendations
+
+
+ Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
+ of IN-ADDR, sometimes in conjunction with a lookup of the name
+ resulting from the PTR record provides no real security, can lead to
+ erroneous results and generally just increases load on DNS servers.
+ Further, in cases where address block holders fail to properly
+ configure IN-ADDR, users of those blocks are penalized.
+
+5. Security Considerations
+
+ This document has no negative impact on security. While it could be
+ argued that lack of PTR record capabilities provides a degree of
+ anonymity, this is really not valid. Trace routes, whois lookups and
+ other sources will still provide methods for discovering identity.
+
+
+
+Senie [Page 4]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ By recommending applications avoid using IN-ADDR as a security
+ mechanism this document points out that this practice, despite its
+ use by many applications, is an ineffective form of security.
+ Applications should use better mechanisms of authentication.
+
+6. IANA Considerations
+
+ There are no IANA considerations for this document.
+
+7. References
+
+7.1 Normative References
+
+ [RFC883] P.V. Mockapetris, "Domain names: Implementation
+ specification," RFC883, November 1983.
+
+ [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
+ Specification," RFC 1035, November 1987.
+
+ [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
+ an Address Assignment and Aggregation Strategy," RFC 1519, September
+ 1993.
+
+ [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
+ RFC 2026, BCP 9, October 1996.
+
+ [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+ [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
+ Guidelines", RFC2050, BCP 12, Novebmer 1996.
+
+ [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
+ RFC 2317, March 1998.
+
+ [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
+ 2001.
+
+7.2 Informative References
+
+ [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
+ unknown, http://www.arin.net/regserv/initial-isp.html
+
+ [APNIC] "Policies For IPv4 Address Space Management in the Asia
+ Pacific Region," APNIC-086, 13 January 2003.
+
+ [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
+ Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
+
+
+
+Senie [Page 5]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ 2004. http://www.ripe.net//ripe/docs/rev-del.html
+
+
+
+8. Acknowledgements
+
+ Thanks to Peter Koch and Gary Miller for their input, and to many
+ people who encouraged me to write this document.
+
+9. Author's Address
+
+ Daniel Senie
+ Amaranth Networks Inc.
+ 324 Still River Road
+ Bolton, MA 01740
+
+ Phone: (978) 779-5100
+
+ EMail: dts@senie.com
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ 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.
+
+
+
+
+Senie [Page 6]
+
+Internet-Draft Encouraging the use of DNS IN-ADDR Mapping July 2005
+
+
+ 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.
+
+ 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
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Senie [Page 7]
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
new file mode 100644
index 0000000..bf2afcd
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
@@ -0,0 +1,1848 @@
+
+
+
+DNS Operations WG J. Jeong, Ed.
+Internet-Draft ETRI/University of Minnesota
+Expires: November 6, 2005 May 5, 2005
+
+
+ IPv6 Host Configuration of DNS Server Information Approaches
+ draft-ietf-dnsop-ipv6-dns-configuration-06.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ 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 6, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document describes three approaches for IPv6 recursive DNS
+ server address configuration. It details the operational attributes
+ of three solutions: RA option, DHCPv6 option, and Well-known anycast
+ addresses for recursive DNS servers. Additionally, it suggests the
+ deployment scenarios in four kinds of networks, such as ISP,
+ Enterprise, 3GPP, and Unmanaged networks, considering multi-solution
+ resolution. Therefore, this document will give the audience a
+
+
+
+Jeong Expires November 6, 2005 [Page 1]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ guideline for IPv6 host DNS configuration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 2]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. IPv6 DNS Configuration Approaches . . . . . . . . . . . . . . 7
+ 3.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 8
+ 3.1.3 Observations . . . . . . . . . . . . . . . . . . . . . 9
+ 3.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 11
+ 3.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 12
+ 3.2.3 Observations . . . . . . . . . . . . . . . . . . . . . 12
+ 3.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 12
+ 3.3.1 Advantages . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.3.2 Disadvantages . . . . . . . . . . . . . . . . . . . . 14
+ 3.3.3 Observations . . . . . . . . . . . . . . . . . . . . . 14
+ 4. Interworking among IPv6 DNS Configuration Approaches . . . . . 15
+ 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1 ISP Network . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1.1 RA Option Approach . . . . . . . . . . . . . . . . . . 16
+ 5.1.2 DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17
+ 5.1.3 Well-known Anycast Addresses Approach . . . . . . . . 17
+ 5.2 Enterprise Network . . . . . . . . . . . . . . . . . . . . 17
+ 5.3 3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18
+ 5.3.1 Currently Available Mechanisms and Recommendations . . 19
+ 5.3.2 RA Extension . . . . . . . . . . . . . . . . . . . . . 19
+ 5.3.3 Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20
+ 5.3.4 Well-known Addresses . . . . . . . . . . . . . . . . . 21
+ 5.3.5 Recommendations . . . . . . . . . . . . . . . . . . . 21
+ 5.4 Unmanaged Network . . . . . . . . . . . . . . . . . . . . 22
+ 5.4.1 Case A: Gateway does not provide IPv6 at all . . . . . 22
+ 5.4.2 Case B: A dual-stack gateway connected to a
+ dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22
+ 5.4.3 Case C: A dual-stack gateway connected to an
+ IPv4-only ISP . . . . . . . . . . . . . . . . . . . . 22
+ 5.4.4 Case D: A gateway connected to an IPv6-only ISP . . . 23
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24
+ 6.1 RA Option . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 6.2 DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 25
+ 6.3 Well-known Anycast Addresses . . . . . . . . . . . . . . . 25
+ 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+ 9.1 Normative References . . . . . . . . . . . . . . . . . . . 29
+ 9.2 Informative References . . . . . . . . . . . . . . . . . . 29
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
+ A. Link-layer Multicast Acknowledgements for RA Option . . . . . 32
+
+
+
+Jeong Expires November 6, 2005 [Page 3]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ Intellectual Property and Copyright Statements . . . . . . . . 33
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 4]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+1. Introduction
+
+ Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
+ Autoconfiguration provide the ways to configure either fixed or
+ mobile nodes with one or more IPv6 addresses, default routes and some
+ other parameters [3][4]. To support the access to additional
+ services in the Internet that are identified by a DNS name, such as a
+ web server, the configuration of at least one recursive DNS server is
+ also needed for DNS name resolution.
+
+ This document describes three approaches of recursive DNS server
+ address configuration for IPv6 host: (a) RA option [8], (b) DHCPv6
+ option [5]-[7], and (c) Well-known anycast addresses for recursive
+ DNS servers [9]. Also, it suggests the applicable scenarios for four
+ kinds of networks: (a) ISP network, (b) Enterprise network, (c) 3GPP
+ network, and (d) Unmanaged network.
+
+ This document is just an analysis of each possible approach, and does
+ not make any recommendation on a particular one or on a combination
+ of particular ones. Some approaches may even not be adopted at all
+ as a result of further discussion.
+
+ Therefore, the objective of this document is to help the audience
+ select the approaches suitable for IPv6 host configuration of
+ recursive DNS servers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 5]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+2. Terminology
+
+ This document uses the terminology described in [3]-[9]. In
+ addition, a new term is defined below:
+
+ o Recursive DNS Server (RDNSS): A Recursive DNS Server is a name
+ server that offers the recursive service of DNS name resolution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 6]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+3. IPv6 DNS Configuration Approaches
+
+ In this section, the operational attributes of the three solutions
+ are described in detail.
+
+3.1 RA Option
+
+ The RA approach is to define a new ND option called the RDNSS option
+ that contains a recursive DNS server address. Existing ND transport
+ mechanisms (i.e., advertisements and solicitations) are used. This
+ works in the same way that nodes learn about routers and prefixes.
+ An IPv6 host can configure the IPv6 addresses of one or more RDNSSes
+ via RA message periodically sent by a router or solicited by a Router
+ Solicitation (RS) [8].
+
+ This approach needs RDNSS information to be configured in the routers
+ doing the advertisements. The configuration of RDNSS addresses can
+ be performed manually by an operator or other ways, such as automatic
+ configuration through a DHCPv6 client running on the router. When
+ advertising more than one RDNSS option, an RA message includes as
+ many RDNSS options as RDNSSes.
+
+ Through the ND protocol and RDNSS option along with a prefix
+ information option, an IPv6 host can perform its network
+ configuration of its IPv6 address and RDNSS simultaneously [3][4].
+ The RA option for RDNSS can be used on any network that supports the
+ use of ND.
+
+ However, it is worth noting that some link layers, such as Wireless
+ LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast,
+ which means that they cannot guarantee the timely delivery of RA
+ messages [25]-[28]. This is discussed in Appendix A.
+
+ The RA approach is useful in some mobile environments where the
+ addresses of the RDNSSes are changing because the RA option includes
+ a lifetime field that allows client to use RDNSSes nearer to the
+ client. This can be configured to a value that will require the
+ client to time out the entry and switch over to another RDNSS address
+ [8]. However, from the viewpoint of implementation, the lifetime
+ field would seem to make matters a bit more complex. Instead of just
+ writing to a DNS configuration file, such as resolv.conf for the list
+ of RDNSS addresses, we have to have a daemon around (or a program
+ that is called at the defined intervals) that keeps monitoring the
+ lifetime of RDNSSes all the time.
+
+ The preference value of RDNSS, included in the RDNSS option, allows
+ IPv6 hosts to select primary RDNSS among several RDNSSes; this can be
+ used for the load balancing of RDNSSes [8].
+
+
+
+Jeong Expires November 6, 2005 [Page 7]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+3.1.1 Advantages
+
+ The RA option for RDNSS has a number of advantages. These include:
+
+ 1. The RA option is an extension of existing ND/Autoconfig
+ mechanisms [3][4], and does not require a change in the base ND
+ protocol.
+
+ 2. This approach, like ND, works well on a variety of link types
+ including point-to-point links, point-to-multipoint, and
+ multipoint-to-multipoint (i.e., Ethernet LANs), etc. RFC 2461
+ [3] states, however, that there may be some link types on which
+ ND is not feasible; on such links, some other mechanisms will be
+ needed for DNS configuration.
+
+ 3. All of the information a host needs to run the basic Internet
+ applications such as the email, web, ftp, etc., can be obtained
+ with the addition of this option to ND and address
+ autoconfiguration. The use of a single mechanism is more
+ reliable and easier to provide than when the RDNSS information is
+ learned via another protocol mechanism. Debugging problems when
+ multiple protocol mechanisms are being used is harder and much
+ more complex.
+
+ 4. This mechanism works over a broad range of scenarios and
+ leverages IPv6 ND. This works well on links that support
+ broadcast reliably (e.g., Ethernet LANs) but not necessarily on
+ other links (e.g., Wireless LANs): Refer to Appendix A. Also,
+ this works well on links that are high performance (e.g.,
+ Ethernet LANs) and low performance (e.g., Cellular networks). In
+ the latter case, by combining the RDNSS information with the
+ other information in the RA, the host can learn all of the
+ information needed to use most Internet applications, such as the
+ web in a single packet. This not only saves bandwidth where this
+ is an issue, but also minimizes the delay needed to learn the
+ RDNSS information.
+
+ 5. The RA approach could be used as a model for other similar types
+ of configuration information. New RA options for other server
+ addresses, such as NTP server address, that are common to all
+ clients on a subnet would be easy to define.
+
+
+3.1.2 Disadvantages
+
+ 1. ND is mostly implemented in the kernel of operating system.
+ Therefore, if ND supports the configuration of some additional
+ services, such as DNS servers, ND should be extended in the
+
+
+
+Jeong Expires November 6, 2005 [Page 8]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ kernel, and complemented by a user-land process. DHCPv6,
+ however, has more flexibility for the extension of service
+ discovery because it is an application layer protocol.
+
+ 2. The current ND framework should be modified to facilitate the
+ synchronization between another ND cache for RDNSSes in the
+ kernel space and the DNS configuration file in the user space.
+ Because it is unacceptable to write and rewrite to the DNS
+ configuration file (e.g., resolv.conf) from the kernel, another
+ approach is needed. One simple approach to solve this is to have
+ a daemon listening to what the kernel conveys, and to have the
+ daemon do these steps, but such a daemon is not needed with the
+ current ND framework.
+
+ 3. It is necessary to configure RDNSS addresses at least at one
+ router on every link where this information needs to be
+ configured via the RA option.
+
+
+3.1.3 Observations
+
+ The proposed RDNSS RA option along with the IPv6 ND and
+ Autoconfiguration allows a host to obtain all of the information it
+ needs to access the basic Internet services like the web, email, ftp,
+ etc. This is preferable in the environments where hosts use RAs to
+ autoconfigure their addresses and all the hosts on the subnet share
+ the same router and server addresses. If the configuration
+ information can be obtained from a single mechanism, it is preferable
+ because it does not add additional delay, and it uses a minimum of
+ bandwidth. The environments like this include the homes, public
+ cellular networks, and enterprise environments where no per host
+ configuration is needed, but exclude public WLAN hot spots.
+
+ DHCPv6 is preferable where it is being used for address configuration
+ and if there is a need for host specific configuration [5]-[7]. The
+ environments like this are most likely to be the enterprise
+ environments where the local administration chooses to have per host
+ configuration control.
+
+Note
+
+ The observation section is based on what the proponents of each
+ approach think makes a good overall solution.
+
+3.2 DHCPv6 Option
+
+ DHCPv6 [5] includes the "DNS Recursive Name Server" option, through
+ which a host can obtain a list of IP addresses of recursive DNS
+
+
+
+Jeong Expires November 6, 2005 [Page 9]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ servers [7]. The DNS Recursive Name Server option carries a list of
+ IPv6 addresses of RDNSSes to which the host may send DNS queries.
+ The DNS servers are listed in the order of preference for use by the
+ DNS resolver on the host.
+
+ The DNS Recursive Name Server option can be carried in any DHCPv6
+ Reply message, in response to either a Request or an Information
+ request message. Thus, the DNS Recursive Name Server option can be
+ used either when DHCPv6 is used for address assignment, or when
+ DHCPv6 is used only for other configuration information as stateless
+ DHCPv6 [6].
+
+ Stateless DHCPv6 can be deployed either using DHCPv6 servers running
+ on general-purpose computers, or on router hardware. Several router
+ vendors currently implement stateless DHCPv6 servers. Deploying
+ stateless DHCPv6 in routers has the advantage that no special
+ hardware is required, and should work well for networks where DHCPv6
+ is needed for very straightforward configuration of network devices.
+
+ However, routers can also act as DHCPv6 relay agents. In this case,
+ the DHCPv6 server need not be on the router - it can be on a general
+ purpose computer. This has the potential to give the operator of the
+ DHCPv6 server more flexibility in how the DHCPv6 server responds to
+ individual clients - clients can easily be given different
+ configuration information based on their identity, or for any other
+ reason. Nothing precludes adding this flexibility to a router, but
+ generally in current practice, DHCP servers running on general-
+ purpose hosts tend to have more configuration options than those that
+ are embedded in routers.
+
+ DHCPv6 currently provides a mechanism for reconfiguring DHCPv6
+ clients that use a stateful configuration assignment. To do this,
+ the DHCPv6 server sends a Reconfigure message to the client. The
+ client validates the Reconfigure message, and then contacts the
+ DHCPv6 server to obtain updated configuration information. Using
+ this mechanism, it is currently possible to propagate new
+ configuration information to DHCPv6 clients as this information
+ changes.
+
+ The DHC Working Group is currently studying an additional mechanism
+ through which configuration information, including the list of
+ RDNSSes, can be updated. The lifetime option for DHCPv6 [10] assigns
+ a lifetime to configuration information obtained through DHCPv6. At
+ the expiration of the lifetime, the host contacts the DHCPv6 server
+ to obtain updated configuration information, including the list of
+ RDNSSes. This lifetime gives the network administrator another
+ mechanism to configure hosts with new RDNSSes by controlling the time
+ at which the host refreshes the list.
+
+
+
+Jeong Expires November 6, 2005 [Page 10]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ The DHC Working Group has also discussed the possibility of defining
+ an extension to DHCPv6 that would allow the use of multicast to
+ provide configuration information to multiple hosts with a single
+ DHCPv6 message. Because of the lack of deployment experience, the WG
+ has deferred consideration of multicast DHCPv6 configuration at this
+ time. Experience with DHCPv4 has not identified a requirement for
+ multicast message delivery, even in large service provider networks
+ with tens of thousands of hosts that may initiate a DHCPv4 message
+ exchange simultaneously.
+
+3.2.1 Advantages
+
+ The DHCPv6 option for RDNSS has a number of advantages. These
+ include:
+
+ 1. DHCPv6 currently provides a general mechanism for conveying
+ network configuration information to clients. So configuring
+ DHCPv6 servers allows the network administrator to configure
+ RDNSSes along with the addresses of other network services, as
+ well as location-specific information like time zones.
+
+ 2. As a consequence, when the network administrator goes to
+ configure DHCPv6, all the configuration information can be
+ managed through a single service, typically with a single user
+ interface and a single configuration database.
+
+ 3. DHCPv6 allows for the configuration of a host with information
+ specific to that host, so that hosts on the same link can be
+ configured with different RDNSSes as well as with other
+ configuration information. This capability is important in some
+ network deployments such as service provider networks or WiFi hot
+ spots.
+
+ 4. A mechanism exists for extending DHCPv6 to support the
+ transmission of additional configuration that has not yet been
+ anticipated.
+
+ 5. Hosts that require other configuration information such as the
+ addresses of SIP servers and NTP servers are likely to need
+ DHCPv6 for other configuration information.
+
+ 6. The specification for configuration of RDNSSes through DHCPv6 is
+ available as an RFC. No new protocol extensions such as new
+ options are necessary.
+
+ 7. Interoperability among independent implementations has been
+ demonstrated.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 11]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+3.2.2 Disadvantages
+
+ The DHCPv6 option for RDNSS has a few disadvantages. These include:
+
+ 1. Update currently requires message from server (however, see
+ [10]).
+
+ 2. Because DNS information is not contained in RA messages, the host
+ must receive two messages from the router, and must transmit at
+ least one message to the router. On networks where bandwidth is
+ at a premium, this is a disadvantage, although on most networks
+ it is not a practical concern.
+
+ 3. Increased latency for initial configuration - in addition to
+ waiting for an RA message, the client must now exchange packets
+ with a DHCPv6 server; even if it is locally installed on a
+ router, this will slightly extend the time required to configure
+ the client. For clients that are moving rapidly from one network
+ to another, this will be a disadvantage.
+
+
+3.2.3 Observations
+
+ In the general case, on general-purpose networks, stateless DHCPv6
+ provides significant advantages and no significant disadvantages.
+ Even in the case where bandwidth is at a premium and low latency is
+ desired, if hosts require other configuration information in addition
+ to a list of RDNSSes or if hosts must be configured selectively,
+ those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive
+ name server option will be advantageous.
+
+ However, we are aware of some applications where it would be
+ preferable to put the RDNSS information into an RA packet; for
+ example, on a cell phone network, where bandwidth is at a premium and
+ extremely low latency is desired. The final DNS configuration draft
+ should be written so as to allow these special applications to be
+ handled using DNS information in the RA packet.
+
+3.3 Well-known Anycast Addresses
+
+ Anycast uses the same routing system as unicast [11]. However,
+ administrative entities are local ones. The local entities may
+ accept unicast routes (including default routes) to anycast servers
+ from adjacent entities. The administrative entities should not
+ advertise their peers routes to their internal anycast servers, if
+ they want to prohibit external access from some peers to the servers.
+ If some advertisement is inevitable (such as the case with default
+ routes), the packets to the servers should be blocked at the boundary
+
+
+
+Jeong Expires November 6, 2005 [Page 12]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ of the entities. Thus, for this anycast, not only unicast routing
+ but also unicast ND protocols can be used as is.
+
+ First of all, the well-known anycast addresses approach is much
+ different from that discussed at IPv6 Working Group in the past [9].
+ It should be noted that "anycast" in this memo is simpler than that
+ of RFC 1546 [11] and RFC 3513 [12] where it is assumed to be
+ prohibited to have multiple servers on a single link sharing an
+ anycast address. That is, on a link, an anycast address is assumed
+ to be unique. DNS clients today already have redundancy by having
+ multiple well-known anycast addresses configured as RDNSS addresses.
+ There is no point in having multiple RDNSSes sharing an anycast
+ address on a single link.
+
+ The approach with well-known anycast addresses is to set multiple
+ well-known anycast addresses in clients' resolver configuration files
+ from the beginning, say, as factory default. Thus, there is no
+ transport mechanism and no packet format [9].
+
+ An anycast address is an address shared by multiple servers (in this
+ case, the servers are RDNSSes). A request from a client to the
+ anycast address is routed to a server selected by the routing system.
+ However, it is a bad idea to mandate "site" boundary on anycast
+ addresses, because most users just do not have their own servers and
+ want to access their ISPs' across their site boundaries. Larger
+ sites may also depend on their ISPs or may have their own RDNSSes
+ within "site" boundaries.
+
+3.3.1 Advantages
+
+ The basic advantage of the well-known addresses approach is that it
+ uses no transport mechanism. Thus,
+
+ 1. There is no delay to get the response and no further delay by
+ packet losses.
+
+ 2. The approach can be combined with any other configuration
+ mechanisms, such as the RA-based approach and DHCP based
+ approach, as well as the factory default configuration.
+
+ 3. The approach works over any environment where DNS works.
+
+ Another advantage is that the approach needs to configure DNS servers
+ as a router, but nothing else. Considering that DNS servers do need
+ configuration, the amount of overall configuration effort is
+ proportional to the number of the DNS servers and scales linearly.
+ It should be noted that, in the simplest case where a subscriber to
+ an ISP does not have any DNS server, the subscriber naturally
+
+
+
+Jeong Expires November 6, 2005 [Page 13]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ accesses DNS servers of the ISP even though the subscriber and the
+ ISP do nothing and there is no protocol to exchange DNS server
+ information between the subscriber and the ISP.
+
+3.3.2 Disadvantages
+
+ Well-known anycast addresses approach requires that DNS servers (or
+ routers near it as a proxy) act as routers to advertise their anycast
+ addresses to the routing system, which requires some configuration
+ (see the last paragraph of the previous section on the scalability of
+ the effort).
+
+3.3.3 Observations
+
+ If other approaches are used in addition, the well-known anycast
+ addresses should also be set in RA or DHCP configuration files to
+ reduce the configuration effort of users.
+
+ The redundancy by multiple RDNSSes is better provided by multiple
+ servers having different anycast addresses than multiple servers
+ sharing the same anycast address because the former approach allows
+ stale servers to still generate routes to their anycast addresses.
+ Thus, in a routing domain (or domains sharing DNS servers), there
+ will be only one server having an anycast address unless the domain
+ is so large that load distribution is necessary.
+
+ Small ISPs will operate one RDNSS at each anycast address which is
+ shared by all the subscribers. Large ISPs may operate multiple
+ RDNSSes at each anycast address to distribute and reduce load, where
+ the boundary between RDNSSes may be fixed (redundancy is still
+ provided by multiple addresses) or change dynamically. DNS packets
+ with the well-known anycast addresses are not expected (though not
+ prohibited) to cross ISP boundaries, as ISPs are expected to be able
+ to take care of themselves.
+
+ Because "anycast" in this memo is simpler than that of RFC 1546 [11]
+ and RFC 3513 [12] where it is assumed to be administratively
+ prohibited to have multiple servers on a single link sharing an
+ anycast address, anycast in this memo should be implemented as
+ UNICAST of RFC 2461 [3] and RFC 3513 [12]. As a result, ND-related
+ instability disappears. Thus, anycast in well-known anycast
+ addresses approach can and should use the anycast address as a source
+ unicast (according to RFC 3513 [12]) address of packets of UDP and
+ TCP responses. With TCP, if a route flips and packets to an anycast
+ address are routed to a new server, it is expected that the flip is
+ detected by ICMP or sequence number inconsistency and the TCP
+ connection is reset and retried.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 14]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+4. Interworking among IPv6 DNS Configuration Approaches
+
+ Three approaches can work together for IPv6 host configuration of
+ RDNSS. This section shows a consideration on how these approaches
+ can interwork each other.
+
+ For ordering between RA and DHCP approaches, the O (Other stateful
+ configuration) flag in RA message can be used [8][32]. If no RDNSS
+ option is included, an IPv6 host may perform DNS configuration
+ through DHCPv6 [5]-[7] regardless of whether the O flag is set or
+ not.
+
+ The well-known anycast addresses approach fully interworks with the
+ other approaches. That is, the other approaches can remove the
+ configuration effort on servers by using the well-known addresses as
+ the default configuration. Moreover, the clients preconfigured with
+ the well-known anycast addresses can be further configured to use
+ other approaches to override the well-known addresses, if the
+ configuration information from other approaches is available.
+ Otherwise, all the clients need to have the well-known anycast
+ addresses preconfigured. In order to use the anycast approach along
+ with two other approaches, there are three choices as follows:
+
+ 1. The first choice is that well-known addresses are used as last
+ resort, when an IPv6 host cannot get RDNSS information through RA
+ and DHCP. The well-known anycast addresses have to be
+ preconfigured in all of IPv6 hosts' resolver configuration files.
+
+ 2. The second is that an IPv6 host can configure well-known
+ addresses as the most preferable in its configuration file even
+ though either an RA option or DHCP option is available.
+
+ 3. The last is that the well-known anycast addresses can be set in
+ RA or DHCP configuration to reduce the configuration effort of
+ users. According to either the RA or DHCP mechanism, the well-
+ known addresses can be obtained by an IPv6 host. Because this
+ approach is the most convenient for users, the last option is
+ recommended.
+
+
+Note
+
+ This section does not necessarily mean this document suggests
+ adopting all these three approaches and making them interwork in the
+ way described here. In fact, some approaches may even not be adopted
+ at all as a result of further discussion.
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 15]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+5. Deployment Scenarios
+
+ Regarding the DNS configuration on the IPv6 host, several mechanisms
+ are being considered at the DNSOP Working Group such as RA option,
+ DHCPv6 option and well-known preconfigured anycast addresses as of
+ today, and this document is a final result from the long thread. In
+ this section, we suggest four applicable scenarios of three
+ approaches for IPv6 DNS configuration.
+
+Note
+
+ In the applicable scenarios, authors do not implicitly push any
+ specific approaches into the restricted environments. No enforcement
+ is in each scenario and all mentioned scenarios are probable. The
+ main objective of this work is to provide a useful guideline for IPv6
+ DNS configuration.
+
+5.1 ISP Network
+
+ A characteristic of ISP network is that multiple Customer Premises
+ Equipment (CPE) devices are connected to IPv6 PE (Provider Edge)
+ routers and each PE connects multiple CPE devices to the backbone
+ network infrastructure [13]. The CPEs may be hosts or routers.
+
+ In the case where the CPE is a router, there is a customer network
+ that is connected to the ISP backbone through the CPE. Typically,
+ each customer network gets a different IPv6 prefix from an IPv6 PE
+ router, but the same RDNSS configuration will be distributed.
+
+ This section discusses how the different approaches to distributing
+ DNS information are compared in an ISP network.
+
+5.1.1 RA Option Approach
+
+ When the CPE is a host, the RA option for RDNSS can be used to allow
+ the CPE to get RDNSS information as well as /64 prefix information
+ for stateless address autoconfiguration at the same time when the
+ host is attached to a new subnet [8]. Because an IPv6 host must
+ receive at least one RA message for stateless address
+ autoconfiguration and router configuration, the host could receive
+ RDNSS configuration information in that RA without the overhead of an
+ additional message exchange.
+
+ When the CPE is a router, the CPE may accept the RDNSS information
+ from the RA on the interface connected to the ISP, and copy that
+ information into the RAs advertised in the customer network.
+
+ This approach is more valuable in the mobile host scenario, in which
+
+
+
+Jeong Expires November 6, 2005 [Page 16]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ the host must receive at least an RA message for detecting a new
+ network, than in other scenarios generally although administrator
+ should configure RDNSS information on the routers. Secure ND [14]
+ can provide extended security when using RA messages.
+
+5.1.2 DHCPv6 Option Approach
+
+ DHCPv6 can be used for RDNSS configuration through the use of the DNS
+ option, and can provide other configuration information in the same
+ message with RDNSS configuration [5]-[7]. The DHCPv6 DNS option is
+ already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or
+ stateless DHCP [6] is nowhere as complex as a full DHCPv6
+ implementation. DHCP is a client-server model protocol, so ISPs can
+ handle user identification on its network intentionally, and also
+ authenticated DHCP [15] can be used for secure message exchange.
+
+ The expected model for deployment of IPv6 service by ISPs is to
+ assign a prefix to each customer, which will be used by the customer
+ gateway to assign a /64 prefix to each network in the customer's
+ network. Prefix delegation with DHCP (DHCPv6 PD) has already been
+ adopted by ISPs for automating the assignment of the customer prefix
+ to the customer gateway [17]. DNS configuration can be carried in
+ the same DHCPv6 message exchange used for DHCPv6 to efficiently
+ provide that information, along with any other configuration
+ information needed by the customer gateway or customer network. This
+ service model can be useful to Home or SOHO subscribers. The Home or
+ SOHO gateway, which is a customer gateway for ISP, can then pass that
+ RDNSS configuration information to the hosts in the customer network
+ through DHCP.
+
+5.1.3 Well-known Anycast Addresses Approach
+
+ The well-known anycast addresses approach is also a feasible and
+ simple mechanism for ISP [9]. The use of well-known anycast
+ addresses avoids some of the security risks in rogue messages sent
+ through an external protocol like RA or DHCPv6. The configuration of
+ hosts for the use of well-known anycast addresses requires no
+ protocol or manual configuration, but the configuration of routing
+ for the anycast addresses requires intervention on the part of the
+ network administrator. Also, the number of special addresses would
+ be equal to the number of RDNSSes that could be made available to
+ subscribers.
+
+5.2 Enterprise Network
+
+ Enterprise network is defined as a network that has multiple internal
+ links, one or more router connections, to one or more Providers and
+ is actively managed by a network operations entity [16]. An
+
+
+
+Jeong Expires November 6, 2005 [Page 17]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ enterprise network can get network prefixes from an ISP by either
+ manual configuration or prefix delegation [17]. In most cases,
+ because an enterprise network manages its own DNS domains, it
+ operates its own DNS servers for the domains. These DNS servers
+ within enterprise network process recursive DNS name resolution
+ requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the
+ enterprise network can be performed like in Section 4, in which three
+ approaches can be used together as follows:
+
+ 1. An IPv6 host can decide which approach is or may be used in its
+ subnet with the O flag in RA message [8][32]. As the first
+ choice in Section 4, well-known anycast addresses can be used as
+ a last resort when RDNSS information cannot be obtained through
+ either an RA option or DHCP option. This case needs IPv6 hosts
+ to preconfigure the well-known anycast addresses in their DNS
+ configuration files.
+
+ 2. When the enterprise prefers the well-known anycast approach to
+ others, IPv6 hosts should preconfigure the well-known anycast
+ addresses like in the first choice.
+
+ 3. The last choice, a more convenient and transparent way, does not
+ need IPv6 hosts to preconfigure the well-known anycast addresses
+ because the addresses are delivered to IPv6 hosts via either the
+ RA option or DHCPv6 option as if they were unicast addresses.
+ This way is most recommended for the sake of user's convenience.
+
+
+5.3 3GPP Network
+
+ The IPv6 DNS configuration is a missing part of IPv6
+ autoconfiguration and an important part of the basic IPv6
+ functionality in the 3GPP User Equipment (UE). The higher level
+ description of the 3GPP architecture can be found in [18], and
+ transition to IPv6 in 3GPP networks is analyzed in [19] and [20].
+
+ In the 3GPP architecture, there is a dedicated link between the UE
+ and the GGSN called the Packet Data Protocol (PDP) Context. This
+ link is created through the PDP Context activation procedure [21].
+ There is a separate PDP context type for IPv4 and IPv6 traffic. If a
+ 3GPP UE user is communicating using IPv6 (having an active IPv6 PDP
+ context), it cannot be assumed that (s)he has simultaneously an
+ active IPv4 PDP context, and DNS queries could be done using IPv4. A
+ 3GPP UE can thus be an IPv6 node, and it needs to somehow discover
+ the address of the RDNSS. Before IP-based services (e.g., web
+ browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses
+ need to be discovered in the 3GPP UE.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 18]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ Section 5.3.1 briefly summarizes currently available mechanisms in
+ 3GPP networks and recommendations. 5.3.2 analyzes the Router
+ Advertisement based solution, 5.3.3 analyzes the Stateless DHCPv6
+ mechanism, and 5.3.4 analyzes the Well-known addresses approach.
+ Section 5.3.5 finally summarizes the recommendations.
+
+5.3.1 Currently Available Mechanisms and Recommendations
+
+ 3GPP has defined a mechanism, in which RDNSS addresses can be
+ received in the PDP context activation (a control plane mechanism).
+ That is called the Protocol Configuration Options Information Element
+ (PCO-IE) mechanism [22]. The RDNSS addresses can also be received
+ over the air (using text messages), or typed in manually in the UE.
+ Note that the two last mechanisms are not very well scalable. The UE
+ user most probably does not want to type IPv6 RDNSS addresses
+ manually in his/her UE. The use of well-known addresses is briefly
+ discussed in section 5.3.4.
+
+ It is seen that the mechanisms above most probably are not sufficient
+ for the 3GPP environment. IPv6 is intended to operate in a zero-
+ configuration manner, no matter what the underlying network
+ infrastructure is. Typically, the RDNSS address is needed to make an
+ IPv6 node operational - and the DNS configuration should be as simple
+ as the address autoconfiguration mechanism. It must also be noted
+ that there will be additional IP interfaces in some near future 3GPP
+ UEs, e.g., WLAN, and 3GPP-specific DNS configuration mechanisms (such
+ as PCO-IE [22]) do not work for those IP interfaces. In other words,
+ a good IPv6 DNS configuration mechanism should also work in a multi-
+ access network environment.
+
+ From a 3GPP point of view, the best IPv6 DNS configuration solution
+ is feasible for a very large number of IPv6-capable UEs (can be even
+ hundreds of millions in one operator's network), is automatic and
+ thus requires no user action. It is suggested to standardize a
+ lightweight, stateless mechanism that works in all network
+ environments. The solution could then be used for 3GPP, 3GPP2, WLAN
+ and other access network technologies. A light, stateless IPv6 DNS
+ configuration mechanism is thus not only needed in 3GPP networks, but
+ also 3GPP networks and UEs would certainly benefit from the new
+ mechanism.
+
+5.3.2 RA Extension
+
+ Router Advertisement extension [8] is a lightweight IPv6 DNS
+ configuration mechanism that requires minor changes in the 3GPP UE
+ IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in
+ the 3GPP architecture) IPv6 stack. This solution can be specified in
+ the IETF (no action needed in the 3GPP) and taken in use in 3GPP UEs
+
+
+
+Jeong Expires November 6, 2005 [Page 19]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ and GGSNs
+
+ In this solution, an IPv6-capable UE configures DNS information via
+ RA message sent by its default router (GGSN), i.e., RDNSS option for
+ recursive DNS server is included in the RA message. This solution is
+ easily scalable for a very large number of UEs. The operator can
+ configure the RDNSS addresses in the GGSN as a part of normal GGSN
+ configuration. The IPv6 RDNSS address is received in the Router
+ Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS
+ addresses can be avoided.
+
+ If thinking about the cons, this mechanism still requires
+ standardization effort in the IETF, and the end nodes and routers
+ need to support this mechanism. The equipment software update
+ should, however, be pretty straightforward, and new IPv6 equipment
+ could support RA extension already from the beginning.
+
+5.3.3 Stateless DHCPv6
+
+ DHCPv6-based solution needs the implementation of Stateless DHCP [6]
+ and DHCPv6 DNS options [7] in the UE, and a DHCPv6 server in the
+ operator's network. A possible configuration is such that the GGSN
+ works as a DHCP relay.
+
+ Pros for Stateless DHCPv6-based solution are
+
+ 1. Stateless DHCPv6 is a standardized mechanism.
+
+ 2. DHCPv6 can be used for receiving other configuration information
+ than RDNSS addresses, e.g., SIP server addresses.
+
+ 3. DHCPv6 works in different network environments.
+
+ 4. When DHCPv6 service is deployed through a single, centralized
+ server, the RDNSS configuration information can be updated by the
+ network administrator at a single source.
+
+ Some issues with DHCPv6 in 3GPP networks are listed below:
+
+ 1. DHCPv6 requires an additional server in the network unless the
+ (Stateless) DHCPv6 functionality is integrated into a router
+ already existing, and that means one box more to be maintained.
+
+ 2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing
+ (3GPP Stateless Address Autoconfiguration is typically used), and
+ not automatically implemented in 3GPP IPv6 UEs.
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 20]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ 3. Scalability and reliability of DHCPv6 in very large 3GPP networks
+ (with tens or hundreds of millions of UEs) may be an issue, at
+ least the redundancy needs to be taken care of. However, if the
+ DHCPv6 service is integrated into the network elements, such as a
+ router operating system, scalability and reliability is
+ comparable with other DNS configuration approaches.
+
+ 4. It is sub-optimal to utilize the radio resources in 3GPP networks
+ for DHCPv6 messages if there is a simpler alternative available.
+
+ * The use of Stateless DHCPv6 adds one round trip delay to the
+ case in which the UE can start transmitting data right after
+ the Router Advertisement.
+
+ 5. If the DNS information (suddenly) changes, Stateless DHCPv6 can
+ not automatically update the UE, see [23].
+
+
+5.3.4 Well-known Addresses
+
+ Using well-known addresses is also a feasible and a light mechanism
+ for 3GPP UEs. Those well-known addresses can be preconfigured in the
+ UE software and the operator makes the corresponding configuration on
+ the network side. So this is a very easy mechanism for the UE, but
+ requires some configuration work in the network. When using well-
+ known addresses, UE forwards queries to any of the preconfigured
+ addresses. In the current proposal [9], IPv6 anycast addresses are
+ suggested.
+
+Note
+
+ The IPv6 DNS configuration proposal based on the use of well-known
+ site-local addresses developed at the IPv6 Working Group was seen as
+ a feasible mechanism for 3GPP UEs, but opposition by some people in
+ the IETF and finally deprecating IPv6 site-local addresses made it
+ impossible to standardize it. Note that this mechanism is
+ implemented in some existing operating systems today (also in some
+ 3GPP UEs) as a last resort of IPv6 DNS configuration.
+
+5.3.5 Recommendations
+
+ It is suggested that a lightweight, stateless DNS configuration
+ mechanism is specified as soon as possible. From a 3GPP UE and
+ network point of view, the Router Advertisement based mechanism looks
+ most promising. The sooner a light, stateless mechanism is
+ specified, the sooner we can get rid of using well-known site-local
+ addresses for IPv6 DNS configuration.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 21]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+5.4 Unmanaged Network
+
+ There are 4 deployment scenarios of interest in unmanaged networks
+ [24]:
+
+ 1. A gateway which does not provide IPv6 at all;
+
+ 2. A dual-stack gateway connected to a dual-stack ISP;
+
+ 3. A dual-stack gateway connected to an IPv4-only ISP; and
+
+ 4. A gateway connected to an IPv6-only ISP.
+
+
+5.4.1 Case A: Gateway does not provide IPv6 at all
+
+ In this case, the gateway does not provide IPv6; the ISP may or may
+ not provide IPv6. Automatic or Configured tunnels are the
+ recommended transition mechanisms for this scenario.
+
+ The case where dual-stack hosts behind an NAT, that need access to an
+ IPv6 RDNSS, cannot be entirely ruled out. The DNS configuration
+ mechanism has to work over the tunnel, and the underlying tunneling
+ mechanism could be implementing NAT traversal. The tunnel server
+ assumes the role of a relay (both for DHCP and Well-known anycast
+ addresses approaches).
+
+ RA-based mechanism is relatively straightforward in its operation,
+ assuming the tunnel server is also the IPv6 router emitting RAs.
+ Well-known anycast addresses approach seems also simple in operation
+ across the tunnel, but the deployment model using Well-known anycast
+ addresses in a tunneled environment is unclear or not well
+ understood.
+
+5.4.2 Case B: A dual-stack gateway connected to a dual-stack ISP
+
+ This is similar to a typical IPv4 home user scenario, where DNS
+ configuration parameters are obtained using DHCP. Except that
+ Stateless DHCPv6 is used, as opposed to the IPv4 scenario where the
+ DHCP server is stateful (maintains the state for clients).
+
+5.4.3 Case C: A dual-stack gateway connected to an IPv4-only ISP
+
+ This is similar to Case B. If a gateway provides IPv6 connectivity by
+ managing tunnels, then it is also supposed to provide access to an
+ RDNSS. Like this, the tunnel for IPv6 connectivity originates from
+ the dual-stack gateway instead of the host.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 22]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+5.4.4 Case D: A gateway connected to an IPv6-only ISP
+
+ This is similar to Case B.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 23]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+6. Security Considerations
+
+ As security requirements depend solely on applications and are
+ different application by application, there can be no generic
+ requirement defined at IP or application layer for DNS.
+
+ However, it should be noted that cryptographic security requires
+ configured secret information that full autoconfiguration and
+ cryptographic security are mutually exclusive. People insisting on
+ secure full autoconfiguration will get false security, false
+ autoconfiguration or both.
+
+ In some deployment scenarios [19], where cryptographic security is
+ required for applications, the secret information for the
+ cryptographic security is preconfigured through which application
+ specific configuration data, including those for DNS, can be securely
+ configured. It should be noted that if applications requiring
+ cryptographic security depend on DNS, the applications also require
+ cryptographic security to DNS. Therefore, the full autoconfiguration
+ of DNS is not acceptable.
+
+ However, with full autoconfiguration, weaker but still reasonable
+ security is being widely accepted and will continue to be acceptable.
+ That is, with full autoconfiguration, which means there is no
+ cryptographic security for the autoconfiguration, it is already
+ assumed that the local environment is secure enough that the
+ information from the local autoconfiguration server has acceptable
+ security even without cryptographic security. Thus, the
+ communication between the local DNS client and local DNS server has
+ acceptable security.
+
+ In autoconfiguring recursive servers, DNSSEC may be overkill, because
+ DNSSEC [29] needs the configuration and reconfiguration of clients at
+ root key roll-over [30][31]. Even if additional keys for secure key
+ roll-over are added at the initial configuration, they are as
+ vulnerable as the original keys to some forms of attacks, such as
+ social hacking. Another problem of using DNSSEC and
+ autoconfiguration together is that DNSSEC requires secure time, which
+ means secure communication with autoconfigured time servers, which
+ requires configured secret information. Therefore, in order that the
+ autoconfiguration may be secure, it requires configured secret
+ information.
+
+ If DNSSEC [29] is used and the signatures are verified on the client
+ host, the misconfiguration of a DNS server may be simply denial of
+ service. Also, if local routing environment is not reliable, clients
+ may be directed to a false resolver with the same IP address as the
+ true one.
+
+
+
+Jeong Expires November 6, 2005 [Page 24]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+6.1 RA Option
+
+ The security of RA option for RDNSS is the same as the ND protocol
+ security [3][8]. The RA option does not add any new vulnerability.
+
+ It should be noted that the vulnerability of ND is not worse and is a
+ subset of the attacks that any node attached to a LAN can do
+ independently of ND. A malicious node on a LAN can promiscuously
+ receive packets for any router's MAC address and send packets with
+ the router's MAC address as the source MAC address in the L2 header.
+ As a result, the L2 switches send packets addressed to the router to
+ the malicious node. Also, this attack can send redirects that tell
+ the hosts to send their traffic somewhere else. The malicious node
+ can send unsolicited RA or NA replies, answer RS or NS requests, etc.
+ All of this can be done independently of implementing ND. Therefore,
+ the RA option for RDNSS does not add to the vulnerability.
+
+ Security issues regarding the ND protocol were discussed at IETF SEND
+ (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND
+ security has been published [14].
+
+6.2 DHCPv6 Option
+
+ The DNS Recursive Name Server option may be used by an intruder DHCP
+ server to cause DHCP clients to send DNS queries to an intruder DNS
+ recursive name server [7]. The results of these misdirected DNS
+ queries may be used to spoof DNS names.
+
+ To avoid attacks through the DNS Recursive Name Server option, the
+ DHCP client SHOULD require DHCP authentication (see section
+ "Authentication of DHCP messages" in RFC 3315 [5]) before installing
+ a list of DNS recursive name servers obtained through authenticated
+ DHCP.
+
+6.3 Well-known Anycast Addresses
+
+ Well-known anycast addresses does not require configuration security
+ since there is no protocol [9].
+
+ The DNS server with the preconfigured addresses are still reasonably
+ reliable, if local environment is reasonably secure, that is, there
+ is no active attackers receiving queries to the anycast addresses of
+ the servers and reply to them.
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 25]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+7. Contributors
+
+ Ralph Droms
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxboro, MA 01719
+ US
+
+ Phone: +1 978 936 1674
+ Email: rdroms@cisco.com
+
+
+ Robert M. Hinden
+ Nokia
+ 313 Fairchild Drive
+ Mountain View, CA 94043
+ US
+
+ Phone: +1 650 625 2004
+ Email: bob.hinden@nokia.com
+
+
+ Ted Lemon
+ Nominum, Inc.
+ 950 Charter Street
+ Redwood City, CA 94043
+ US
+
+ Email: Ted.Lemon@nominum.com
+
+
+ Masataka Ohta
+ Tokyo Institute of Technology
+ 2-12-1, O-okayama, Meguro-ku
+ Tokyo 152-8552
+ Japan
+
+ Phone: +81 3 5734 3299
+ Fax: +81 3 5734 3299
+ Email: mohta@necom830.hpcl.titech.ac.jp
+
+
+ Soohong Daniel Park
+ Mobile Platform Laboratory, SAMSUNG Electronics
+ 416 Maetan-3dong, Yeongtong-Gu
+ Suwon, Gyeonggi-Do 443-742
+ Korea
+
+
+
+
+Jeong Expires November 6, 2005 [Page 26]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ Phone: +82 31 200 4508
+ Email: soohong.park@samsung.com
+
+
+ Suresh Satapati
+ Cisco Systems, Inc.
+ San Jose, CA 95134
+ US
+
+ Email: satapati@cisco.com
+
+
+ Juha Wiljakka
+ Nokia
+ Visiokatu 3
+ FIN-33720, TAMPERE
+ Finland
+
+ Phone: +358 7180 48372
+ Email: juha.wiljakka@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 27]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+8. Acknowledgements
+
+ This draft has greatly benefited from inputs by David Meyer, Rob
+ Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
+ Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
+ Also, Tony Bonanno proofread this draft. The authors appreciate
+ their contribution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 28]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+9. References
+
+9.1 Normative References
+
+ [1] Bradner, S., "IETF Rights in Contributions", RFC 3667,
+ February 2004.
+
+ [2] Bradner, S., "Intellectual Property Rights in IETF Technology",
+ RFC 3668, February 2004.
+
+ [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
+ for IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+ [4] Thomson, S. and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [5] Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6
+ (DHCPv6)", RFC 3315, July 2003.
+
+ [6] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
+ Service for IPv6", RFC 3736, April 2004.
+
+ [7] Droms, R., Ed., "DNS Configuration options for Dynamic Host
+ Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+ December 2003.
+
+9.2 Informative References
+
+ [8] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS
+ Discovery based on Router Advertisement",
+ draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress),
+ February 2005.
+
+ [9] Ohta, M., "Preconfigured DNS Server Addresses",
+ draft-ohta-preconfigured-dns-01.txt (Work in Progress),
+ February 2004.
+
+ [10] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
+ Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in
+ Progress), January 2005.
+
+ [11] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
+ Service", RFC 1546, November 1993.
+
+ [12] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+ Addressing Architecture", RFC 3513, April 2003.
+
+ [13] Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6
+
+
+
+Jeong Expires November 6, 2005 [Page 29]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ into ISP Networks", RFC 4029, March 2005.
+
+ [14] Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971,
+ March 2005.
+
+ [15] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
+ RFC 3118, June 2001.
+
+ [16] Bound, J., Ed., "IPv6 Enterprise Network Scenarios",
+ draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress),
+ July 2004.
+
+ [17] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
+ Configuration Protocol (DHCP) version 6", RFC 3633,
+ December 2003.
+
+ [18] Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP
+ Standards", RFC 3314, September 2002.
+
+ [19] Soininen, J., Ed., "Transition Scenarios for 3GPP Networks",
+ RFC 3574, August 2003.
+
+ [20] Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP
+ Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in
+ Progress), October 2004.
+
+ [21] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS);
+ Service description; Stage 2 (Release 5)", December 2002.
+
+ [22] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3
+ specification; Core network protocols; Stage 3 (Release 5)",
+ June 2003.
+
+ [23] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
+ Requirements for Stateless DHCPv6",
+ draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in
+ Progress), October 2004.
+
+ [24] Huitema, C., Ed., "Unmanaged Networks IPv6 Transition
+ Scenarios", RFC 3750, April 2004.
+
+ [25] ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access
+ Control (MAC) and Physical Layer (PHY) Specifications",
+ March 1999.
+
+ [26] IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control
+ (MAC) and Physical Layer (PHY) specifications: High-speed
+ Physical Layer in the 5 GHZ Band", September 1999.
+
+
+
+Jeong Expires November 6, 2005 [Page 30]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+ [27] IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control
+ (MAC) and Physical Layer (PHY) specifications: Higher-Speed
+ Physical Layer Extension in the 2.4 GHz Band", September 1999.
+
+ [28] IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access
+ Control (MAC) and Physical Layer (PHY) specifications: Further
+ Higher Data Rate Extension in the 2.4 GHz Band", April 2003.
+
+ [29] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [30] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
+ draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in
+ Progress), December 2004.
+
+ [31] Guette, G. and O. Courtay, "Requirements for Automated Key
+ Rollover in DNSSEC",
+ draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in
+ Progress), January 2005.
+
+ [32] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
+ and O Flags of IPv6 Router Advertisement",
+ draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress),
+ March 2005.
+
+
+Author's Address
+
+ Jaehoon Paul Jeong (editor)
+ ETRI/Department of Computer Science and Engineering
+ University of Minnesota
+ 117 Pleasant Street SE
+ Minneapolis, MN 55455
+ US
+
+ Phone: +1 651 587 7774
+ Fax: +1 612 625 2002
+ Email: jjeong@cs.umn.edu
+ URI: http://www.cs.umn.edu/~jjeong/
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 31]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+Appendix A. Link-layer Multicast Acknowledgements for RA Option
+
+ One benefit of an RA option [8] is to be able to multicast the
+ advertisements, reducing the need for duplicated unicast
+ communications.
+
+ However, some link-layers may not support this as well as others.
+ Consider, for example, WLAN networks where multicast is unreliable.
+ The unreliability problem is caused by lack of ACK for multicast,
+ especially on the path from the Access Point (AP) to the Station
+ (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11
+ a/b/g [25]-[28]. That is, a multicast packet is unacknowledged on
+ the path from the AP to the STA, but acknowledged in the reverse
+ direction from the STA to the AP [25]. For example, when a router is
+ placed at wired network connected to an AP, a host may sometimes not
+ receive RA message advertised through the AP. Therefore, the RA
+ option solution might not work well on a congested medium that uses
+ unreliable multicast for RA.
+
+ The fact that this problem has not been addressed in Neighbor
+ Discovery [3] indicates that the extra link-layer acknowledgements
+ have not been considered a serious problem till now.
+
+ A possible mitigation technique could be to map all-nodes link- local
+ multicast address to the link-layer broadcast address, and to rely on
+ the ND retransmissions for message delivery in order to achieve more
+ reliability.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong Expires November 6, 2005 [Page 32]
+
+Internet-Draft IPv6 Host Configuration of DNS Server May 2005
+
+
+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 (2005). 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.
+
+
+
+
+Jeong Expires November 6, 2005 [Page 33]
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
new file mode 100644
index 0000000..1276f9f
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
@@ -0,0 +1,1682 @@
+
+
+
+
+DNS Operations WG A. Durand
+Internet-Draft SUN Microsystems, Inc.
+Expires: January 17, 2006 J. Ihren
+ Autonomica
+ P. Savola
+ CSC/FUNET
+ July 16, 2005
+
+
+ Operational Considerations and Issues with IPv6 DNS
+ draft-ietf-dnsop-ipv6-dns-issues-11.txt
+
+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 January 17, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This memo presents operational considerations and issues with IPv6
+ Domain Name System (DNS), including a summary of special IPv6
+ addresses, documentation of known DNS implementation misbehaviour,
+ recommendations and considerations on how to perform DNS naming for
+ service provisioning and for DNS resolver IPv6 support,
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 1]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ considerations for DNS updates for both the forward and reverse
+ trees, and miscellaneous issues. This memo is aimed to include a
+ summary of information about IPv6 DNS considerations for those who
+ have experience with IPv4 DNS.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4
+ 1.2 Independence of DNS Transport and DNS Records . . . . . . 4
+ 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5
+ 1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5
+ 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5
+ 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6
+ 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6
+ 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6
+ 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7
+ 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7
+ 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7
+ 4. Recommendations for Service Provisioning using DNS . . . . . . 7
+ 4.1 Use of Service Names instead of Node Names . . . . . . . . 8
+ 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8
+ 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9
+ 4.4 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
+ 4.4.1 TTL With Courtesy Additional Data . . . . . . . . . . 10
+ 4.4.2 TTL With Critical Additional Data . . . . . . . . . . 10
+ 4.5 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11
+ 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11
+ 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
+ 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13
+ 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 13
+ 6. Considerations about Forward DNS Updating . . . . . . . . . . 13
+ 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
+ 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14
+ 7. Considerations about Reverse DNS Updating . . . . . . . . . . 15
+ 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
+ 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
+ 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16
+ 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
+ 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18
+ 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
+ 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19
+ 8.2 Renumbering Procedures and Applications' Use of DNS . . . 19
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . 20
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 11.1 Normative References . . . . . . . . . . . . . . . . . . . 20
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 2]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ 11.2 Informative References . . . . . . . . . . . . . . . . . . 22
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
+ A. Unique Local Addressing Considerations for DNS . . . . . . . . 25
+ B. Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25
+ B.1 Description of Additional Data Scenarios . . . . . . . . . 26
+ B.2 Which Additional Data to Keep, If Any? . . . . . . . . . . 27
+ B.3 Discussion of the Potential Problems . . . . . . . . . . . 28
+ Intellectual Property and Copyright Statements . . . . . . . . 30
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 3]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+1. Introduction
+
+ This memo presents operational considerations and issues with IPv6
+ DNS; it is meant to be an extensive summary and a list of pointers
+ for more information about IPv6 DNS considerations for those with
+ experience with IPv4 DNS.
+
+ The purpose of this document is to give information about various
+ issues and considerations related to DNS operations with IPv6; it is
+ not meant to be a normative specification or standard for IPv6 DNS.
+
+ The first section gives a brief overview of how IPv6 addresses and
+ names are represented in the DNS, how transport protocols and
+ resource records (don't) relate, and what IPv4/IPv6 name space
+ fragmentation means and how to avoid it; all of these are described
+ at more length in other documents.
+
+ The second section summarizes the special IPv6 address types and how
+ they relate to DNS. The third section describes observed DNS
+ implementation misbehaviours which have a varying effect on the use
+ of IPv6 records with DNS. The fourth section lists recommendations
+ and considerations for provisioning services with DNS. The fifth
+ section in turn looks at recommendations and considerations about
+ providing IPv6 support in the resolvers. The sixth and seventh
+ sections describe considerations with forward and reverse DNS
+ updates, respectively. The eighth section introduces several
+ miscellaneous IPv6 issues relating to DNS for which no better place
+ has been found in this memo. Appendix A looks briefly at the
+ requirements for unique local addressing.
+
+1.1 Representing IPv6 Addresses in DNS Records
+
+ In the forward zones, IPv6 addresses are represented using AAAA
+ records. In the reverse zones, IPv6 address are represented using
+ PTR records in the nibble format under the ip6.arpa. tree. See
+ [RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
+ for background information.
+
+ In particular one should note that the use of A6 records in the
+ forward tree or Bitlabels in the reverse tree is not recommended
+ [RFC3363]. Using DNAME records is not recommended in the reverse
+ tree in conjunction with A6 records; the document did not mean to
+ take a stance on any other use of DNAME records [RFC3364].
+
+1.2 Independence of DNS Transport and DNS Records
+
+ DNS has been designed to present a single, globally unique name space
+ [RFC2826]. This property should be maintained, as described here and
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 4]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ in Section 1.3.
+
+ The IP version used to transport the DNS queries and responses is
+ independent of the records being queried: AAAA records can be queried
+ over IPv4, and A records over IPv6. The DNS servers must not make
+ any assumptions about what data to return for Answer and Authority
+ sections based on the underlying transport used in a query.
+
+ However, there is some debate whether the addresses in Additional
+ section could be selected or filtered using hints obtained from which
+ transport was being used; this has some obvious problems because in
+ many cases the transport protocol does not correlate with the
+ requests, and because a "bad" answer is in a way worse than no answer
+ at all (consider the case where the client is led to believe that a
+ name received in the additional record does not have any AAAA records
+ at all).
+
+ As stated in [RFC3596]:
+
+ The IP protocol version used for querying resource records is
+ independent of the protocol version of the resource records; e.g.,
+ IPv4 transport can be used to query IPv6 records and vice versa.
+
+
+1.3 Avoiding IPv4/IPv6 Name Space Fragmentation
+
+ To avoid the DNS name space from fragmenting into parts where some
+ parts of DNS are only visible using IPv4 (or IPv6) transport, the
+ recommendation is to always keep at least one authoritative server
+ IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
+ See DNS IPv6 transport guidelines [RFC3901] for more information.
+
+1.4 Query Type '*' and A/AAAA Records
+
+ QTYPE=* is typically only used for debugging or management purposes;
+ it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
+ any available RRsets, not *all* the RRsets, because the caches do not
+ necessarily have all the RRsets and have no way of guaranteeing that
+ they have all the RRsets. Therefore, to get both A and AAAA records
+ reliably, two separate queries must be made.
+
+2. DNS Considerations about Special IPv6 Addresses
+
+ There are a couple of IPv6 address types which are somewhat special;
+ these are considered here.
+
+
+
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 5]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+2.1 Limited-scope Addresses
+
+ The IPv6 addressing architecture [RFC3513] includes two kinds of
+ local-use addresses: link-local (fe80::/10) and site-local
+ (fec0::/10). The site-local addresses have been deprecated [RFC3879]
+ but are discussed with unique local addresses in Appendix A.
+
+ Link-local addresses should never be published in DNS (whether in
+ forward or reverse tree), because they have only local (to the
+ connected link) significance [I-D.durand-dnsop-dont-publish].
+
+2.2 Temporary Addresses
+
+ Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
+ "privacy addresses") use a random number as the interface identifier.
+ Having DNS AAAA records that are updated to always contain the
+ current value of a node's temporary address would defeat the purpose
+ of the mechanism and is not recommended. However, it would still be
+ possible to return a non-identifiable name (e.g., the IPv6 address in
+ hexadecimal format), as described in [RFC3041].
+
+2.3 6to4 Addresses
+
+ 6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
+ a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
+
+ If the reverse DNS population would be desirable (see Section 7.1 for
+ applicability), there are a number of possible ways to do so.
+
+ The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
+ autonomous reverse-delegation system that anyone being capable of
+ communicating using a specific 6to4 address would be able to set up a
+ reverse delegation to the corresponding 6to4 prefix. This could be
+ deployed by e.g., Regional Internet Registries (RIRs). This is a
+ practical solution, but may have some scalability concerns.
+
+2.4 Other Transition Mechanisms
+
+ 6to4 is mentioned as a case of an IPv6 transition mechanism requiring
+ special considerations. In general, mechanisms which include a
+ special prefix may need a custom solution; otherwise, for example
+ when IPv4 address is embedded as the suffix or not embedded at all,
+ special solutions are likely not needed.
+
+ Note that it does not seem feasible to provide reverse DNS with
+ another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
+ teredo]; this is because the IPv6 address is based on the IPv4
+ address and UDP port of the current NAT mapping which is likely to be
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 6]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ relatively short-lived.
+
+3. Observed DNS Implementation Misbehaviour
+
+ Several classes of misbehaviour in DNS servers, load-balancers and
+ resolvers have been observed. Most of these are rather generic, not
+ only applicable to IPv6 -- but in some cases, the consequences of
+ this misbehaviour are extremely severe in IPv6 environments and
+ deserve to be mentioned.
+
+3.1 Misbehaviour of DNS Servers and Load-balancers
+
+ There are several classes of misbehaviour in certain DNS servers and
+ load-balancers which have been noticed and documented [RFC4074]: some
+ implementations silently drop queries for unimplemented DNS records
+ types, or provide wrong answers to such queries (instead of a proper
+ negative reply). While typically these issues are not limited to
+ AAAA records, the problems are aggravated by the fact that AAAA
+ records are being queried instead of (mainly) A records.
+
+ The problems are serious because when looking up a DNS name, typical
+ getaddrinfo() implementations, with AF_UNSPEC hint given, first try
+ to query the AAAA records of the name, and after receiving a
+ response, query the A records. This is done in a serial fashion --
+ if the first query is never responded to (instead of properly
+ returning a negative answer), significant timeouts will occur.
+
+ In consequence, this is an enormous problem for IPv6 deployments, and
+ in some cases, IPv6 support in the software has even been disabled
+ due to these problems.
+
+ The solution is to fix or retire those misbehaving implementations,
+ but that is likely not going to be effective. There are some
+ possible ways to mitigate the problem, e.g., by performing the
+ lookups somewhat in parallel and reducing the timeout as long as at
+ least one answer has been received; but such methods remain to be
+ investigated; slightly more on this is included in Section 5.
+
+3.2 Misbehaviour of DNS Resolvers
+
+ Several classes of misbehaviour have also been noticed in DNS
+ resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem
+ to directly impair IPv6 use, and are only referred to for
+ completeness.
+
+4. Recommendations for Service Provisioning using DNS
+
+ When names are added in the DNS to facilitate a service, there are
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 7]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ several general guidelines to consider to be able to do it as
+ smoothly as possible.
+
+4.1 Use of Service Names instead of Node Names
+
+ It makes sense to keep information about separate services logically
+ separate in the DNS by using a different DNS hostname for each
+ service. There are several reasons for doing this, for example:
+
+ o It allows more flexibility and ease for migration of (only a part
+ of) services from one node to another,
+
+ o It allows configuring different properties (e.g., TTL) for each
+ service, and
+
+ o It allows deciding separately for each service whether to publish
+ the IPv6 addresses or not (in cases where some services are more
+ IPv6-ready than others).
+
+ Using SRV records [RFC2782] would avoid these problems.
+ Unfortunately, those are not sufficiently widely used to be
+ applicable in most cases. Hence an operation technique is to use
+ service names instead of node names (or, "hostnames"). This
+ operational technique is not specific to IPv6, but required to
+ understand the considerations described in Section 4.2 and
+ Section 4.3.
+
+ For example, assume a node named "pobox.example.com" provides both
+ SMTP and IMAP service. Instead of configuring the MX records to
+ point at "pobox.example.com", and configuring the mail clients to
+ look up the mail via IMAP from "pobox.example.com", one could use
+ e.g., "smtp.example.com" for SMTP (for both message submission and
+ mail relaying between SMTP servers) and "imap.example.com" for IMAP.
+ Note that in the specific case of SMTP relaying, the server itself
+ must typically also be configured to know all its names to ensure
+ loops do not occur. DNS can provide a layer of indirection between
+ service names and where the service actually is, and using which
+ addresses. (Obviously, when wanting to reach a specific node, one
+ should use the hostname rather than a service name.)
+
+4.2 Separate vs the Same Service Names for IPv4 and IPv6
+
+ The service naming can be achieved in basically two ways: when a
+ service is named "service.example.com" for IPv4, the IPv6-enabled
+ service could either be added to "service.example.com", or added
+ separately under a different name, e.g., in a sub-domain, like,
+ "service.ipv6.example.com".
+
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 8]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ These two methods have different characteristics. Using a different
+ name allows for easier service piloting, minimizing the disturbance
+ to the "regular" users of IPv4 service; however, the service would
+ not be used transparently, without the user/application explicitly
+ finding it and asking for it -- which would be a disadvantage in most
+ cases. When the different name is under a sub-domain, if the
+ services are deployed within a restricted network (e.g., inside an
+ enterprise), it's possible to prefer them transparently, at least to
+ a degree, by modifying the DNS search path; however, this is a
+ suboptimal solution. Using the same service name is the "long-term"
+ solution, but may degrade performance for those clients whose IPv6
+ performance is lower than IPv4, or does not work as well (see
+ Section 4.3 for more).
+
+ In most cases, it makes sense to pilot or test a service using
+ separate service names, and move to the use of the same name when
+ confident enough that the service level will not degrade for the
+ users unaware of IPv6.
+
+4.3 Adding the Records Only when Fully IPv6-enabled
+
+ The recommendation is that AAAA records for a service should not be
+ added to the DNS until all of following are true:
+
+ 1. The address is assigned to the interface on the node.
+
+ 2. The address is configured on the interface.
+
+ 3. The interface is on a link which is connected to the IPv6
+ infrastructure.
+
+ In addition, if the AAAA record is added for the node, instead of
+ service as recommended, all the services of the node should be IPv6-
+ enabled prior to adding the resource record.
+
+ For example, if an IPv6 node is isolated from an IPv6 perspective
+ (e.g., it is not connected to IPv6 Internet) constraint #3 would mean
+ that it should not have an address in the DNS.
+
+ Consider the case of two dual-stack nodes, which both have IPv6
+ enabled, but the server does not have (global) IPv6 connectivity. As
+ the client looks up the server's name, only A records are returned
+ (if the recommendations above are followed), and no IPv6
+ communication, which would have been unsuccessful, is even attempted.
+
+ The issues are not always so black-and-white. Usually it's important
+ that the service offered using both protocols is of roughly equal
+ quality, using the appropriate metrics for the service (e.g.,
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 9]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ latency, throughput, low packet loss, general reliability, etc.) --
+ this is typically very important especially for interactive or real-
+ time services. In many cases, the quality of IPv6 connectivity may
+ not yet be equal to that of IPv4, at least globally -- this has to be
+ taken into consideration when enabling services.
+
+4.4 The Use of TTL for IPv4 and IPv6 RRs
+
+ The behaviour of DNS caching when different TTL values are used for
+ different RRsets of the same name calls for explicit discussion. For
+ example, let's consider two unrelated zone fragments:
+
+ example.com. 300 IN MX foo.example.com.
+ foo.example.com. 300 IN A 192.0.2.1
+ foo.example.com. 100 IN AAAA 2001:db8::1
+
+ ...
+
+ child.example.com. 300 IN NS ns.child.example.com.
+ ns.child.example.com. 300 IN A 192.0.2.1
+ ns.child.example.com. 100 IN AAAA 2001:db8::1
+
+ In the former case, we have "courtesy" additional data; in the
+ latter, we have "critical" additional data. See more extensive
+ background discussion of additional data handling in Appendix B.
+
+4.4.1 TTL With Courtesy Additional Data
+
+ When a caching resolver asks for the MX record of example.com, it
+ gets back "foo.example.com". It may also get back either one or both
+ of the A and AAAA records in the additional section. The resolver
+ must explicitly query for both A and AAAA records [RFC2821].
+
+ After 100 seconds, the AAAA record is removed from the cache(s)
+ because its TTL expired. It could be argued to be useful for the
+ caching resolvers to discard the A record when the shorter TTL (in
+ this case, for the AAAA record) expires; this would avoid the
+ situation where there would be a window of 200 seconds when
+ incomplete information is returned from the cache. Further argument
+ for discarding is that in the normal operation, the TTL values are so
+ high that very likely the incurred additional queries would not be
+ noticeable, compared to the obtained performance optimization. The
+ behaviour in this scenario is unspecified.
+
+4.4.2 TTL With Critical Additional Data
+
+ The difference to courtesy additional data is that the A/AAAA records
+ served by the parent zone cannot be queried explicitly. Therefore
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 10]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ after 100 seconds the AAAA record is removed from the cache(s), but
+ the A record remains. Queries for the remaining 200 seconds
+ (provided that there are no further queries from the parent which
+ could refresh the caches) only return the A record, leading to a
+ potential opererational situation with unreachable servers.
+
+ Similar cache flushing strategies apply in this scenario; the record.
+
+4.5 IPv6 Transport Guidelines for DNS Servers
+
+ As described in Section 1.3 and [RFC3901], there should continue to
+ be at least one authoritative IPv4 DNS server for every zone, even if
+ the zone has only IPv6 records. (Note that obviously, having more
+ servers with robust connectivity would be preferable, but this is the
+ minimum recommendation; also see [RFC2182].)
+
+5. Recommendations for DNS Resolver IPv6 Support
+
+ When IPv6 is enabled on a node, there are several things to consider
+ to ensure that the process is as smooth as possible.
+
+5.1 DNS Lookups May Query IPv6 Records Prematurely
+
+ The system library that implements the getaddrinfo() function for
+ looking up names is a critical piece when considering the robustness
+ of enabling IPv6; it may come in basically three flavours:
+
+ 1. The system library does not know whether IPv6 has been enabled in
+ the kernel of the operating system: it may start looking up AAAA
+ records with getaddrinfo() and AF_UNSPEC hint when the system is
+ upgraded to a system library version which supports IPv6.
+
+ 2. The system library might start to perform IPv6 queries with
+ getaddrinfo() only when IPv6 has been enabled in the kernel.
+ However, this does not guarantee that there exists any useful
+ IPv6 connectivity (e.g., the node could be isolated from the
+ other IPv6 networks, only having link-local addresses).
+
+ 3. The system library might implement a toggle which would apply
+ some heuristics to the "IPv6-readiness" of the node before
+ starting to perform queries; for example, it could check whether
+ only link-local IPv6 address(es) exists, or if at least one
+ global IPv6 address exists.
+
+ First, let us consider generic implications of unnecessary queries
+ for AAAA records: when looking up all the records in the DNS, AAAA
+ records are typically tried first, and then A records. These are
+ done in serial, and the A query is not performed until a response is
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 11]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ received to the AAAA query. Considering the misbehaviour of DNS
+ servers and load-balancers, as described in Section 3.1, the look-up
+ delay for AAAA may incur additional unnecessary latency, and
+ introduce a component of unreliability.
+
+ One option here could be to do the queries partially in parallel; for
+ example, if the final response to the AAAA query is not received in
+ 0.5 seconds, start performing the A query while waiting for the
+ result (immediate parallelism might be unoptimal, at least without
+ information sharing between the look-up threads, as that would
+ probably lead to duplicate non-cached delegation chain lookups).
+
+ An additional concern is the address selection, which may, in some
+ circumstances, prefer AAAA records over A records even when the node
+ does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
+ In some cases, the implementation may attempt to connect or send a
+ datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
+ incurring very long protocol timeouts, instead of quickly failing
+ back to IPv4.
+
+ Now, we can consider the issues specific to each of the three
+ possibilities:
+
+ In the first case, the node performs a number of completely useless
+ DNS lookups as it will not be able to use the returned AAAA records
+ anyway. (The only exception is where the application desires to know
+ what's in the DNS, but not use the result for communication.) One
+ should be able to disable these unnecessary queries, for both latency
+ and reliability reasons. However, as IPv6 has not been enabled, the
+ connections to IPv6 addresses fail immediately, and if the
+ application is programmed properly, the application can fall
+ gracefully back to IPv4 [RFC4038].
+
+ The second case is similar to the first, except it happens to a
+ smaller set of nodes when IPv6 has been enabled but connectivity has
+ not been provided yet; similar considerations apply, with the
+ exception that IPv6 records, when returned, will be actually tried
+ first which may typically lead to long timeouts.
+
+ The third case is a bit more complex: optimizing away the DNS lookups
+ with only link-locals is probably safe (but may be desirable with
+ different lookup services which getaddrinfo() may support), as the
+ link-locals are typically automatically generated when IPv6 is
+ enabled, and do not indicate any form of IPv6 connectivity. That is,
+ performing DNS lookups only when a non-link-local address has been
+ configured on any interface could be beneficial -- this would be an
+ indication that either the address has been configured either from a
+ router advertisement, DHCPv6 [RFC3315], or manually. Each would
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 12]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ indicate at least some form of IPv6 connectivity, even though there
+ would not be guarantees of it.
+
+ These issues should be analyzed at more depth, and the fixes found
+ consensus on, perhaps in a separate document.
+
+5.2 Obtaining a List of DNS Recursive Resolvers
+
+ In scenarios where DHCPv6 is available, a host can discover a list of
+ DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
+ option [RFC3646]. This option can be passed to a host through a
+ subset of DHCPv6 [RFC3736].
+
+ The IETF is considering the development of alternative mechanisms for
+ obtaining the list of DNS recursive name servers when DHCPv6 is
+ unavailable or inappropriate. No decision about taking on this
+ development work has been reached as of this writing (Aug 2004)
+ [I-D.ietf-dnsop-ipv6-dns-configuration].
+
+ In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
+ under consideration for development include the use of well-known
+ addresses [I-D.ohta-preconfigured-dns] and the use of Router
+ Advertisements to convey the information [I-D.jeong-dnsop-ipv6-dns-
+ discovery].
+
+ Note that even though IPv6 DNS resolver discovery is a recommended
+ procedure, it is not required for dual-stack nodes in dual-stack
+ networks as IPv6 DNS records can be queried over IPv4 as well as
+ IPv6. Obviously, nodes which are meant to function without manual
+ configuration in IPv6-only networks must implement the DNS resolver
+ discovery function.
+
+5.3 IPv6 Transport Guidelines for Resolvers
+
+ As described in Section 1.3 and [RFC3901], the recursive resolvers
+ should be IPv4-only or dual-stack to be able to reach any IPv4-only
+ DNS server. Note that this requirement is also fulfilled by an IPv6-
+ only stub resolver pointing to a dual-stack recursive DNS resolver.
+
+6. Considerations about Forward DNS Updating
+
+ While the topic of how to enable updating the forward DNS, i.e., the
+ mapping from names to the correct new addresses, is not specific to
+ IPv6, it should be considered especially due to the advent of
+ Stateless Address Autoconfiguration [RFC2462].
+
+ Typically forward DNS updates are more manageable than doing them in
+ the reverse DNS, because the updater can often be assumed to "own" a
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 13]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ certain DNS name -- and we can create a form of security relationship
+ with the DNS name and the node which is allowed to update it to point
+ to a new address.
+
+ A more complex form of DNS updates -- adding a whole new name into a
+ DNS zone, instead of updating an existing name -- is considered out
+ of scope for this memo as it could require zone-wide authentication.
+ Adding a new name in the forward zone is a problem which is still
+ being explored with IPv4, and IPv6 does not seem to add much new in
+ that area.
+
+6.1 Manual or Custom DNS Updates
+
+ The DNS mappings can also be maintained by hand, in a semi-automatic
+ fashion or by running non-standardized protocols. These are not
+ considered at more length in this memo.
+
+6.2 Dynamic DNS
+
+ Dynamic DNS updates (DDNS) [RFC2136] [RFC3007] is a standardized
+ mechanism for dynamically updating the DNS. It works equally well
+ with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
+ address configuration. It is important to consider how each of these
+ behave if IP address-based authentication, instead of stronger
+ mechanisms [RFC3007], was used in the updates.
+
+ 1. manual addresses are static and can be configured
+
+ 2. DHCPv6 addresses could be reasonably static or dynamic, depending
+ on the deployment, and could or could not be configured on the
+ DNS server for the long term
+
+ 3. SLAAC addresses are typically stable for a long time, but could
+ require work to be configured and maintained.
+
+ As relying on IP addresses for Dynamic DNS is rather insecure at
+ best, stronger authentication should always be used; however, this
+ requires that the authorization keying will be explicitly configured
+ using unspecified operational methods.
+
+ Note that with DHCP it is also possible that the DHCP server updates
+ the DNS, not the host. The host might only indicate in the DHCP
+ exchange which hostname it would prefer, and the DHCP server would
+ make the appropriate updates. Nonetheless, while this makes setting
+ up a secure channel between the updater and the DNS server easier, it
+ does not help much with "content" security, i.e., whether the
+ hostname was acceptable -- if the DNS server does not include
+ policies, they must be included in the DHCP server (e.g., a regular
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 14]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ host should not be able to state that its name is "www.example.com").
+ DHCP-initiated DDNS updates have been extensively described in
+ [I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
+ [I-D.ietf-dnsext-dhcid-rr].
+
+ The nodes must somehow be configured with the information about the
+ servers where they will attempt to update their addresses, sufficient
+ security material for authenticating themselves to the server, and
+ the hostname they will be updating. Unless otherwise configured, the
+ first could be obtained by looking up the authoritative name servers
+ for the hostname; the second must be configured explicitly unless one
+ chooses to trust the IP address-based authentication (not a good
+ idea); and lastly, the nodename is typically pre-configured somehow
+ on the node, e.g., at install time.
+
+ Care should be observed when updating the addresses not to use longer
+ TTLs for addresses than are preferred lifetimes for the addresses, so
+ that if the node is renumbered in a managed fashion, the amount of
+ stale DNS information is kept to the minimum. That is, if the
+ preferred lifetime of an address expires, the TTL of the record needs
+ be modified unless it was already done before the expiration. For
+ better flexibility, the DNS TTL should be much shorter (e.g., a half
+ or a third) than the lifetime of an address; that way, the node can
+ start lowering the DNS TTL if it seems like the address has not been
+ renewed/refreshed in a while. Some discussion on how an
+ administrator could manage the DNS TTL is included in [I-D.ietf-
+ v6ops-renumbering-procedure]; this could be applied to (smart) hosts
+ as well.
+
+7. Considerations about Reverse DNS Updating
+
+ Updating the reverse DNS zone may be difficult because of the split
+ authority over an address. However, first we have to consider the
+ applicability of reverse DNS in the first place.
+
+7.1 Applicability of Reverse DNS
+
+ Today, some applications use reverse DNS to either look up some hints
+ about the topological information associated with an address (e.g.
+ resolving web server access logs), or as a weak form of a security
+ check, to get a feel whether the user's network administrator has
+ "authorized" the use of the address (on the premises that adding a
+ reverse record for an address would signal some form of
+ authorization).
+
+ One additional, maybe slightly more useful usage is ensuring that the
+ reverse and forward DNS contents match (by looking up the pointer to
+ the name by the IP address from the reverse tree, and ensuring that a
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 15]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ record under the name in the forward tree points to the IP address)
+ and correspond to a configured name or domain. As a security check,
+ it is typically accompanied by other mechanisms, such as a user/
+ password login; the main purpose of the reverse+forward DNS check is
+ to weed out the majority of unauthorized users, and if someone
+ managed to bypass the checks, he would still need to authenticate
+ "properly".
+
+ It may also be desirable to store IPsec keying material corresponding
+ to an IP address in the reverse DNS, as justified and described in
+ [RFC4025].
+
+ It is not clear whether it makes sense to require or recommend that
+ reverse DNS records be updated. In many cases, it would just make
+ more sense to use proper mechanisms for security (or topological
+ information lookup) in the first place. At minimum, the applications
+ which use it as a generic authorization (in the sense that a record
+ exists at all) should be modified as soon as possible to avoid such
+ lookups completely.
+
+ The applicability is discussed at more length in [I-D.ietf-dnsop-
+ inaddr-required].
+
+7.2 Manual or Custom DNS Updates
+
+ Reverse DNS can of course be updated using manual or custom methods.
+ These are not further described here, except for one special case.
+
+ One way to deploy reverse DNS would be to use wildcard records, for
+ example, by configuring one name for a subnet (/64) or a site (/48).
+ As a concrete example, a site (or the site's ISP) could configure the
+ reverses of the prefix 2001:db8:f00::/48 to point to one name using a
+ wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
+ site.example.com." Naturally, such a name could not be verified from
+ the forward DNS, but would at least provide some form of "topological
+ information" or "weak authorization" if that is really considered to
+ be useful. Note that this is not actually updating the DNS as such,
+ as the whole point is to avoid DNS updates completely by manually
+ configuring a generic name.
+
+7.3 DDNS with Stateless Address Autoconfiguration
+
+ Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
+ some regard, while being more difficult in another, as described
+ below.
+
+ The address space administrator decides whether the hosts are trusted
+ to update their reverse DNS records or not. If they are trusted and
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 16]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ deployed at the same site (e.g., not across the Internet), a simple
+ address-based authorization is typically sufficient (i.e., check that
+ the DNS update is done from the same IP address as the record being
+ updated); stronger security can also be used [RFC3007]. If they
+ aren't allowed to update the reverses, no update can occur. However,
+ such address-based update authorization operationally requires that
+ ingress filtering [RFC3704] has been set up at the border of the site
+ where the updates occur, and as close to the updater as possible.
+
+ Address-based authorization is simpler with reverse DNS (as there is
+ a connection between the record and the address) than with forward
+ DNS. However, when a stronger form of security is used, forward DNS
+ updates are simpler to manage because the host can be assumed to have
+ an association with the domain. Note that the user may roam to
+ different networks, and does not necessarily have any association
+ with the owner of that address space -- so, assuming stronger form of
+ authorization for reverse DNS updates than an address association is
+ generally infeasible.
+
+ Moreover, the reverse zones must be cleaned up by an unspecified
+ janitorial process: the node does not typically know a priori that it
+ will be disconnected, and cannot send a DNS update using the correct
+ source address to remove a record.
+
+ A problem with defining the clean-up process is that it is difficult
+ to ensure that a specific IP address and the corresponding record are
+ no longer being used. Considering the huge address space, and the
+ unlikelihood of collision within 64 bits of the interface
+ identifiers, a process which would remove the record after no traffic
+ has been seen from a node in a long period of time (e.g., a month or
+ year) might be one possible approach.
+
+ To insert or update the record, the node must discover the DNS server
+ to send the update to somehow, similar to as discussed in
+ Section 6.2. One way to automate this is looking up the DNS server
+ authoritative (e.g., through SOA record) for the IP address being
+ updated, but the security material (unless the IP address-based
+ authorization is trusted) must also be established by some other
+ means.
+
+ One should note that Cryptographically Generated Addresses [RFC3972]
+ (CGAs) may require a slightly different kind of treatment. CGAs are
+ addresses where the interface identifier is calculated from a public
+ key, a modifier (used as a nonce), the subnet prefix, and other data.
+ Depending on the usage profile, CGAs might or might not be changed
+ periodically due to e.g., privacy reasons. As the CGA address is not
+ predicatable, a reverse record can only reasonably be inserted in the
+ DNS by the node which generates the address.
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 17]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+7.4 DDNS with DHCP
+
+ With DHCPv4, the reverse DNS name is typically already inserted to
+ the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One
+ can assume similar practice may become commonplace with DHCPv6 as
+ well; all such mappings would be pre-configured, and would require no
+ updating.
+
+ If a more explicit control is required, similar considerations as
+ with SLAAC apply, except for the fact that typically one must update
+ a reverse DNS record instead of inserting one (if an address
+ assignment policy that reassigns disused addresses is adopted) and
+ updating a record seems like a slightly more difficult thing to
+ secure. However, it is yet uncertain how DHCPv6 is going to be used
+ for address assignment.
+
+ Note that when using DHCP, either the host or the DHCP server could
+ perform the DNS updates; see the implications in Section 6.2.
+
+ If disused addresses were to be reassigned, host-based DDNS reverse
+ updates would need policy considerations for DNS record modification,
+ as noted above. On the other hand, if disused address were not to be
+ assigned, host-based DNS reverse updates would have similar
+ considerations as SLAAC in Section 7.3. Server-based updates have
+ similar properties except that the janitorial process could be
+ integrated with DHCP address assignment.
+
+7.5 DDNS with Dynamic Prefix Delegation
+
+ In cases where a prefix, instead of an address, is being used and
+ updated, one should consider what is the location of the server where
+ DDNS updates are made. That is, where the DNS server is located:
+
+ 1. At the same organization as the prefix delegator.
+
+ 2. At the site where the prefixes are delegated to. In this case,
+ the authority of the DNS reverse zone corresponding to the
+ delegated prefix is also delegated to the site.
+
+ 3. Elsewhere; this implies a relationship between the site and where
+ DNS server is located, and such a relationship should be rather
+ straightforward to secure as well. Like in the previous case,
+ the authority of the DNS reverse zone is also delegated.
+
+ In the first case, managing the reverse DNS (delegation) is simpler
+ as the DNS server and the prefix delegator are in the same
+ administrative domain (as there is no need to delegate anything at
+ all); alternatively, the prefix delegator might forgo DDNS reverse
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 18]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ capability altogether, and use e.g., wildcard records (as described
+ in Section 7.2). In the other cases, it can be slighly more
+ difficult, particularly as the site will have to configure the DNS
+ server to be authoritative for the delegated reverse zone, implying
+ automatic configuration of the DNS server -- as the prefix may be
+ dynamic.
+
+ Managing the DDNS reverse updates is typically simple in the second
+ case, as the updated server is located at the local site, and
+ arguably IP address-based authentication could be sufficient (or if
+ not, setting up security relationships would be simpler). As there
+ is an explicit (security) relationship between the parties in the
+ third case, setting up the security relationships to allow reverse
+ DDNS updates should be rather straightforward as well (but IP
+ address-based authentication might not be acceptable). In the first
+ case, however, setting up and managing such relationships might be a
+ lot more difficult.
+
+8. Miscellaneous DNS Considerations
+
+ This section describes miscellaneous considerations about DNS which
+ seem related to IPv6, for which no better place has been found in
+ this document.
+
+8.1 NAT-PT with DNS-ALG
+
+ The DNS-ALG component of NAT-PT mangles A records to look like AAAA
+ records to the IPv6-only nodes. Numerous problems have been
+ identified with DNS-ALG [I-D.ietf-v6ops-natpt-to-exprmntl]. This is
+ a strong reason not to use NAT-PT in the first place.
+
+8.2 Renumbering Procedures and Applications' Use of DNS
+
+ One of the most difficult problems of systematic IP address
+ renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
+ an application which looks up a DNS name disregards information such
+ as TTL, and uses the result obtained from DNS as long as it happens
+ to be stored in the memory of the application. For applications
+ which run for a long time, this could be days, weeks or even months;
+ some applications may be clever enough to organize the data
+ structures and functions in such a manner that look-ups get refreshed
+ now and then.
+
+ While the issue appears to have a clear solution, "fix the
+ applications", practically this is not reasonable immediate advice;
+ the TTL information is not typically available in the APIs and
+ libraries (so, the advice becomes "fix the applications, APIs and
+ libraries"), and a lot more analysis is needed on how to practically
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 19]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ go about to achieve the ultimate goal of avoiding using the names
+ longer than expected.
+
+9. Acknowledgements
+
+ Some recommendations (Section 4.3, Section 5.1) about IPv6 service
+ provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
+ Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided
+ useful feedback and improvements. Scott Rose, Rob Austein, Masataka
+ Ohta, and Mark Andrews helped in clarifying the issues regarding
+ additional data and the use of TTL. Jefsey Morfin, Ralph Droms,
+ Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
+ Rob Austein provided useful feedback during the WG last call. Thomas
+ Narten provided extensive feedback during the IESG evaluation.
+
+10. Security Considerations
+
+ This document reviews the operational procedures for IPv6 DNS
+ operations and does not have security considerations in itself.
+
+ However, it is worth noting that in particular with Dynamic DNS
+ Updates, security models based on the source address validation are
+ very weak and cannot be recommended -- they could only be considered
+ in the environments where ingress filtering [RFC3704] has been
+ deployed. On the other hand, it should be noted that setting up an
+ authorization mechanism (e.g., a shared secret, or public-private
+ keys) between a node and the DNS server has to be done manually, and
+ may require quite a bit of time and expertise.
+
+ To re-emphasize what was already stated, the reverse+forward DNS
+ check provides very weak security at best, and the only
+ (questionable) security-related use for them may be in conjunction
+ with other mechanisms when authenticating a user.
+
+11. References
+
+11.1 Normative References
+
+ [I-D.ietf-dnsop-ipv6-dns-configuration]
+ Jeong, J., "IPv6 Host Configuration of DNS Server
+ Information Approaches",
+ draft-ietf-dnsop-ipv6-dns-configuration-06 (work in
+ progress), May 2005.
+
+ [I-D.ietf-ipv6-unique-local-addr]
+ Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+ Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
+ progress), January 2005.
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 20]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ [I-D.ietf-v6ops-renumbering-procedure]
+ Baker, F., "Procedures for Renumbering an IPv6 Network
+ without a Flag Day",
+ draft-ietf-v6ops-renumbering-procedure-05 (work in
+ progress), March 2005.
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC2136] Vixie, P., 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.
+
+ [RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
+ and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
+ July 1997.
+
+ [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
+ RFC 2671, August 1999.
+
+ [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+ April 2001.
+
+ [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+ [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
+ Stateless Address Autoconfiguration in IPv6", RFC 3041,
+ January 2001.
+
+ [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
+ via IPv4 Clouds", RFC 3056, February 2001.
+
+ [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+ August 2001.
+
+ [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+ and M. Carney, "Dynamic Host Configuration Protocol for
+ IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+ [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+ Hain, "Representing Internet Protocol version 6 (IPv6)
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 21]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ Addresses in the Domain Name System (DNS)", RFC 3363,
+ August 2002.
+
+ [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
+ Support for Internet Protocol version 6 (IPv6)", RFC 3364,
+ August 2002.
+
+ [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
+ (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+ [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IP Version 6", RFC 3596,
+ October 2003.
+
+ [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
+ Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
+ December 2003.
+
+ [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
+ (DHCP) Service for IPv6", RFC 3736, April 2004.
+
+ [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
+ Addresses", RFC 3879, September 2004.
+
+ [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
+ Guidelines", BCP 91, RFC 3901, September 2004.
+
+ [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
+ Castro, "Application Aspects of IPv6 Transition",
+ RFC 4038, March 2005.
+
+ [RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
+ DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
+
+11.2 Informative References
+
+ [I-D.durand-dnsop-dont-publish]
+ Durand, A. and T. Chown, "To publish, or not to publish,
+ that is the question.", draft-durand-dnsop-dont-publish-00
+ (work in progress), February 2005.
+
+ [I-D.huitema-v6ops-teredo]
+ Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+ NATs", draft-huitema-v6ops-teredo-05 (work in progress),
+ April 2005.
+
+ [I-D.huston-6to4-reverse-dns]
+ Huston, G., "6to4 Reverse DNS Delegation",
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 22]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ draft-huston-6to4-reverse-dns-03 (work in progress),
+ October 2004.
+
+ [I-D.ietf-dhc-ddns-resolution]
+ Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
+ DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in
+ progress), June 2005.
+
+ [I-D.ietf-dhc-fqdn-option]
+ Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
+ draft-ietf-dhc-fqdn-option-10 (work in progress),
+ February 2005.
+
+ [I-D.ietf-dnsext-dhcid-rr]
+ Stapp, M., Lemon, T., and A. Gustafsson, "A DNS RR for
+ encoding DHCP information (DHCID RR)",
+ draft-ietf-dnsext-dhcid-rr-09 (work in progress),
+ February 2005.
+
+ [I-D.ietf-dnsop-bad-dns-res]
+ Larson, M. and P. Barber, "Observed DNS Resolution
+ Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in
+ progress), October 2004.
+
+ [I-D.ietf-dnsop-inaddr-required]
+ Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
+ draft-ietf-dnsop-inaddr-required-06 (work in progress),
+ February 2005.
+
+ [I-D.ietf-v6ops-3gpp-analysis]
+ Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
+ Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
+ progress), October 2004.
+
+ [I-D.ietf-v6ops-mech-v2]
+ Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
+ for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07
+ (work in progress), March 2005.
+
+ [I-D.ietf-v6ops-natpt-to-exprmntl]
+ Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
+ Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
+ in progress), July 2005.
+
+ [I-D.ietf-v6ops-onlinkassumption]
+ Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
+ Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
+ (work in progress), May 2005.
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 23]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ [I-D.ietf-v6ops-v6onbydefault]
+ Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
+ IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
+ (work in progress), July 2004.
+
+ [I-D.jeong-dnsop-ipv6-dns-discovery]
+ Jeong, J., "IPv6 DNS Configuration based on Router
+ Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04
+ (work in progress), February 2005.
+
+ [I-D.ohta-preconfigured-dns]
+ Ohta, M., "Preconfigured DNS Server Addresses",
+ draft-ohta-preconfigured-dns-01 (work in progress),
+ February 2004.
+
+ [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
+ Translation - Protocol Translation (NAT-PT)", RFC 2766,
+ February 2000.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC2826] Internet Architecture Board, "IAB Technical Comment on the
+ Unique DNS Root", RFC 2826, May 2000.
+
+ [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
+ Networks", BCP 84, RFC 3704, March 2004.
+
+ [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
+ RFC 3972, March 2005.
+
+ [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
+ Material in DNS", RFC 4025, March 2005.
+
+
+Authors' Addresses
+
+ Alain Durand
+ SUN Microsystems, Inc.
+ 17 Network circle UMPL17-202
+ Menlo Park, CA 94025
+ USA
+
+ Email: Alain.Durand@sun.com
+
+
+
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 24]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ Johan Ihren
+ Autonomica
+ Bellmansgatan 30
+ SE-118 47 Stockholm
+ Sweden
+
+ Email: johani@autonomica.se
+
+
+ Pekka Savola
+ CSC/FUNET
+ Espoo
+ Finland
+
+ Email: psavola@funet.fi
+
+Appendix A. Unique Local Addressing Considerations for DNS
+
+ Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have
+ replaced the now-deprecated site-local addresses [RFC3879]. From the
+ perspective of the DNS, the locally generated unique local addresses
+ (LUL) and site-local addresses have similar properties.
+
+ The interactions with DNS come in two flavors: forward and reverse
+ DNS.
+
+ To actually use local addresses within a site, this implies the
+ deployment of a "split-faced" or a fragmented DNS name space, for the
+ zones internal to the site, and the outsiders' view to it. The
+ procedures to achieve this are not elaborated here. The implication
+ is that local addresses must not be published in the public DNS.
+
+ To faciliate reverse DNS (if desired) with local addresses, the stub
+ resolvers must look for DNS information from the local DNS servers,
+ not e.g. starting from the root servers, so that the local
+ information may be provided locally. Note that the experience of
+ private addresses in IPv4 has shown that the root servers get loaded
+ for requests for private address lookups in any case. This
+ requirement is discussed in [I-D.ietf-ipv6-unique-local-addr].
+
+Appendix B. Behaviour of Additional Data in IPv4/IPv6 Environments
+
+ DNS responses do not always fit in a single UDP packet. We'll
+ examine the cases which happen when this is due to too much data in
+ the Additional Section.
+
+
+
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 25]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+B.1 Description of Additional Data Scenarios
+
+ There are two kinds of additional data:
+
+ 1. "critical" additional data; this must be included in all
+ scenarios, with all the RRsets, and
+
+ 2. "courtesy" additional data; this could be sent in full, with only
+ a few RRsets, or with no RRsets, and can be fetched separately as
+ well, but at the cost of additional queries.
+
+ The responding server can algorithmically determine which type the
+ additional data is by checking whether it's at or below a zone cut.
+
+ Only those additional data records (even if sometimes carelessly
+ termed "glue") are considered "critical" or real "glue" if and only
+ if they meet the abovementioned condition, as specified in Section
+ 4.2.1 of [RFC1034].
+
+ Remember that resource record sets (RRsets) are never "broken up", so
+ if a name has 4 A records and 5 AAAA records, you can either return
+ all 9, all 4 A records, all 5 AAAA records or nothing. In
+ particular, notice that for the "critical" additional data getting
+ all the RRsets can be critical.
+
+ In particular, [RFC2181] specifies (in Section 9) that:
+
+ a. if all the "critical" RRsets do not fit, the sender should set
+ the TC bit, and the recipient should discard the whole response
+ and retry using mechanism allowing larger responses such as TCP.
+
+ b. "courtesy" additional data should not cause the setting of TC
+ bit, but instead all the non-fitting additional data RRsets
+ should be removed.
+
+ An example of the "courtesy" additional data is A/AAAA records in
+ conjunction with MX records as shown in Section 4.4; an example of
+ the "critical" additional data is shown below (where getting both the
+ A and AAAA RRsets is critical w.r.t. to the NS RR):
+
+ child.example.com. IN NS ns.child.example.com.
+ ns.child.example.com. IN A 192.0.2.1
+ ns.child.example.com. IN AAAA 2001:db8::1
+
+ When there is too much "courtesy" additional data, at least the non-
+ fitting RRsets should be removed [RFC2181]; however, as the
+ additional data is not critical, even all of it could be safely
+ removed.
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 26]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ When there is too much "critical" additional data, TC bit will have
+ to be set, and the recipient should ignore the response and retry
+ using TCP; if some data were to be left in the UDP response, the
+ issue is which data could be retained.
+
+ Failing to discard the response with TC bit or omitting critical
+ information but not setting TC bit lead to an unrecoverable problem.
+ Omitting only some of the RRsets if all would not fit (but not
+ setting TC bit) leads to a performance problem. These are discussed
+ in the next two subsections.
+
+B.2 Which Additional Data to Keep, If Any?
+
+ If the implementation decides to keep as much data (whether
+ "critical" or "courtesy") as possible in the UDP responses, it might
+ be tempting to use the transport of the DNS query as a hint in either
+ of these cases: return the AAAA records if the query was done over
+ IPv6, or return the A records if the query was done over IPv4.
+ However, this breaks the model of independence of DNS transport and
+ resource records, as noted in Section 1.2.
+
+ With courtesy additional data, as long as enough RRsets will be
+ removed so that TC will not be set, it is allowed to send as many
+ complete RRsets as the implementations prefers. However, the
+ implementations are also free to omit all such RRsets, even if
+ complete. Omitting all the RRsets (when removing only some would
+ suffice) may create a performance penalty, whereby the client may
+ need to issue one or more additional queries to obtain necessary
+ and/or consistent information.
+
+ With critical additional data, the alternatives are either returning
+ nothing (and absolutely requiring a retry with TCP) or returning
+ something (working also in the case if the recipient does not discard
+ the response and retry using TCP) in addition to setting the TC bit.
+ If the process for selecting "something" from the critical data would
+ otherwise be practically "flipping the coin" between A and AAAA
+ records, it could be argued that if one looked at the transport of
+ the query, it would have a larger possibility of being right than
+ just 50/50. In other words, if the returned critical additional data
+ would have to be selected somehow, using something more sophisticated
+ than a random process would seem justifiable.
+
+ That is, leaving in some intelligently selected critical additional
+ data is a tradeoff between creating an optimization for those
+ resolvers which ignore the "should discard" recommendation, and
+ causing a protocol problem by propagating inconsistent information
+ about "critical" records in the caches.
+
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 27]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ Similarly, leaving in the complete courtesy additional data RRsets
+ instead of removing all the RRsets is a performance tradeoff as
+ described in the next section.
+
+B.3 Discussion of the Potential Problems
+
+ As noted above, the temptation for omitting only some of the
+ additional data could be problematic. This is discussed more below.
+
+ For courtesy additional data, this causes a potential performance
+ problem as this requires that the clients issue re-queries for the
+ potentially omitted RRsets. For critical additional data, this
+ causes a potential unrecoverable problem if the response is not
+ discarded and the query not re-tried with TCP, as the nameservers
+ might be reachable only through the omitted RRsets.
+
+ If an implementation would look at the transport used for the query,
+ it is worth remembering that often the host using the records is
+ different from the node requesting them from the authoritative DNS
+ server (or even a caching resolver). So, whichever version the
+ requestor (e.g., a recursive server in the middle) uses makes no
+ difference to the ultimate user of the records, whose transport
+ capabilities might differ from those of the requestor. This might
+ result in e.g., inappropriately returning A records to an IPv6-only
+ node, going through a translation, or opening up another IP-level
+ session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
+ Therefore, at least in many scenarios, it would be very useful if the
+ information returned would be consistent and complete -- or if that
+ is not feasible, return no misleading information but rather leave it
+ to the client to query again.
+
+ The problem of too much additional data seems to be an operational
+ one: the zone administrator entering too many records which will be
+ returned either truncated (or missing some RRsets, depending on
+ implementations) to the users. A protocol fix for this is using
+ EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
+ pushing up the relevant threshold. Further, DNS server
+ implementations should rather omit courtesy additional data
+ completely rather than including only some RRsets [RFC2181]. An
+ operational fix for this is having the DNS server implementations
+ return a warning when the administrators create zones which would
+ result in too much additional data being returned. Further, DNS
+ server implementations should warn of or disallow such zone
+ configurations which are recursive or otherwise difficult to manage
+ by the protocol.
+
+ Additionally, to avoid the case where an application would not get an
+ address at all due to some of courtesy additional data being omitted,
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 28]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+ the resolvers should be able to query the specific records of the
+ desired protocol, not just rely on getting all the required RRsets in
+ the additional section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 29]
+
+Internet-Draft Considerations with IPv6 DNS July 2005
+
+
+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 (2005). 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.
+
+
+
+
+Durand, et al. Expires January 17, 2006 [Page 30]
+
+
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
new file mode 100644
index 0000000..b2e2341
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
@@ -0,0 +1,300 @@
+Internet Engineering Task Force A.Durand
+INTERNET-DRAFT SUN Microsystems,inc.
+November, 24, 2003 J. Ihren
+Expires May 25, 2004 Autonomica
+
+
+ DNS IPv6 transport operational guidelines
+ <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
+
+
+
+Status of this Memo
+
+ This memo provides information to the Internet community. It does not
+ specify an Internet standard of any kind. This memo is in full
+ conformance with all provisions of Section 10 of RFC2026
+
+ 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
+
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+
+Abstract
+
+ This memo provides guidelines and Best Current Practice to operate
+ DNS in a world where queries and responses are carried in a mixed
+ environment of IPv4 and IPv6 networks.
+
+
+Acknowledgment
+
+ This document is the result of many conversations that happened in
+ the DNS community at IETF and elsewhere since 2001. During that
+ period of time, a number of Internet drafts have been published to
+ clarify various aspects of the issues at stake. This document focuses
+ on the conclusion of those discussions.
+
+ The authors would like to acknowledge the role of Pekka Savola in his
+ thorough review of the document.
+
+
+1. Terminology
+
+ The phrase "IPv4 name server" indicates a name server available over
+ IPv4 transport. It does not imply anything about what DNS data is
+ served. Likewise, "IPv6 name server" indicates a name server
+ available over IPv6 transport. The phrase "dual-stack DNS server"
+ indicates a DNS server that is actually configured to run both
+ protocols, IPv4 and IPv6, and not merely a server running on a system
+ capable of running both but actually configured to run only one.
+
+ 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 [2119].
+
+
+2. Introduction to the Problem of Name Space Fragmentation:
+ following the referral chain
+
+ The caching resolver that tries to look up a name starts out at the
+ root, and follows referrals until it is referred to a nameserver that
+ is authoritative for the name. If somewhere down the chain of
+ referrals it is referred to a nameserver that is only accessible over
+ an unavailable type of transport, a traditional nameserver is unable
+ to finish the task.
+
+ When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
+ only a matter of time until this starts to happen. The complete DNS
+ hierarchy then starts to fragment into a graph where authoritative
+ nameservers for certain nodes are only accessible over a certain
+ transport. What is feared is that a node using only a particular
+ version of IP, querying information about another node using the same
+ version of IP can not do it because, somewhere in the chain of
+ servers accessed during the resolution process, one or more of them
+ will only be accessible with the other version of IP.
+
+ With all DNS data only available over IPv4 transport everything is
+ simple. IPv4 resolvers can use the intended mechanism of following
+ referrals from the root and down while IPv6 resolvers have to work
+ through a "translator", i.e. they have to use a second name server on
+ a so-called "dual stack" host as a "forwarder" since they cannot
+ access the DNS data directly.
+
+ With all DNS data only available over IPv6 transport everything would
+ be equally simple, with the exception of old legacy IPv4 name servers
+ having to switch to a forwarding configuration.
+
+ However, the second situation will not arise in a foreseeable time.
+ Instead, it is expected that the transition will be from IPv4 only to
+ a mixture of IPv4 and IPv6, with DNS data of theoretically three
+ categories depending on whether it is available only over IPv4
+ transport, only over IPv6 or both.
+
+ Having DNS data available on both transports is the best situation.
+ The major question is how to ensure that it as quickly as possible
+ becomes the norm. However, while it is obvious that some DNS data
+ will only be available over v4 transport for a long time it is also
+ obvious that it is important to avoid fragmenting the name space
+ available to IPv4 only hosts. I.e. during transition it is not
+ acceptable to break the name space that we presently have available
+ for IPv4-only hosts.
+
+
+3. Policy Based Avoidance of Name Space Fragmentation
+
+ Today there are only a few DNS "zones" on the public Internet that
+ are available over IPv6 transport, and most of them can be regarded
+ as "experimental". However, as soon as the root and top level domains
+ are available over IPv6 transport, it is reasonable to expect that it
+ will become more common to have zones served by IPv6 servers.
+
+ Having those zones served only by IPv6-only name server would not be
+ a good development, since this will fragment the previously
+ unfragmented IPv4 name space and there are strong reasons to find a
+ mechanism to avoid it.
+
+ The RECOMMENDED approach to maintain name space continuity is to use
+ administrative policies, as described in the next section.
+
+
+4. DNS IPv6 Transport RECOMMENDED Guidelines
+
+ In order to preserve name space continuity, the following administrative
+ policies are RECOMMENDED:
+ - every recursive DNS server SHOULD be either IPv4-only or dual
+ stack,
+ - every single DNS zone SHOULD be served by at least one IPv4
+ reachable DNS server.
+
+ This rules out IPv6-only DNS servers performing full recursion and
+ DNS zones served only by IPv6-only DNS servers. However, one could
+ very well design a configuration where a chain of IPv6 only DNS
+ servers forward queries to a set of dual stack DNS servers actually
+ performing those recursive queries. This approach could be revisited
+ if/when translation techniques between IPv4 and IPv6 were to be
+ widely deployed.
+
+ In order to help enforcing the second point, the optional operational
+ zone validation processes SHOULD ensure that there is at least one
+ IPv4 address record available for the name servers of any child
+ delegations within the zone.
+
+
+5. Security Considerations
+
+ Being a critical piece of the Internet infrastructure, the DNS is a
+ potential value target and thus should be protected. Great care
+ should be taken not to weaken the security of DNS while introducing
+ IPv6 operation.
+
+ Keeping the DNS name space from fragmenting is a critical thing for
+ the availability and the operation of the Internet; this memo
+ addresses this issue by clear and simple operational guidelines.
+
+ The RECOMMENDED guidelines are compatible with the operation of
+ DNSSEC and do not introduce any new security issues.
+
+
+6. Author Addresses
+
+ Alain Durand
+ SUN Microsystems, Inc
+ 17 Network circle UMPK17-202
+ Menlo Park, CA, 94025
+ USA
+ Mail: Alain.Durand@sun.com
+
+ Johan Ihren
+ Autonomica
+ Bellmansgatan 30
+ SE-118 47 Stockholm, Sweden
+ Mail: johani@autonomica.se
+
+
+7. Normative References
+
+ [2119] Bradner, S., "Key Words for Use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+8. Full Copyright Statement
+
+ "Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
new file mode 100644
index 0000000..6bece56
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
@@ -0,0 +1,389 @@
+
+DNSOP G. Guette
+Internet-Draft IRISA / INRIA
+Expires: July 19, 2005 O. Courtay
+ Thomson R&D
+ January 18, 2005
+
+ Requirements for Automated Key Rollover in DNSSEC
+ draft-ietf-dnsop-key-rollover-requirements-02.txt
+
+Status of this Memo
+
+ By submitting this Internet-Draft, I certify that any applicable
+ patent or other IPR claims of which I am aware have been disclosed,
+ and any of which I become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ 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 July 19, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+Abstract
+
+ This document describes problems that appear during an automated
+ rollover and gives the requirements for the design of communication
+ between parent zone and child zone during an automated rollover
+ process. This document is essentially about in-band key rollover.
+
+
+
+
+Guette & Courtay Expires July 19, 2005 [Page 1]
+Internet-Draft Automated Rollover Requirements January 2005
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
+ 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Messages authentication and information exchanged . . . . . . 5
+ 5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. Security consideration . . . . . . . . . . . . . . . . . . . . 6
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
+ 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
+ A. Documents details and changes . . . . . . . . . . . . . . . . 7
+ Intellectual Property and Copyright Statements . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guette & Courtay Expires July 19, 2005 [Page 2]
+Internet-Draft Automated Rollover Requirements January 2005
+
+1. Introduction
+
+ The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
+ cryptography and digital signatures. It stores the public part of
+ keys in DNSKEY Resource Records (RRs). Because old keys and
+ frequently used keys are vulnerable, they must be renewed
+ periodically. In DNSSEC, this is the case for Zone Signing Keys
+ (ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key
+ exchanges between parents and children is necessary for large zones
+ because there are too many changes to handle.
+
+ Let us consider for example a zone with 100000 secure delegations.
+ If the child zones change their keys once a year on average, that
+ implies 300 changes per day for the parent zone. This amount of
+ changes is hard to manage manually.
+
+ Automated rollover is optional and resulting from an agreement
+ between the administrator of the parent zone and the administrator of
+ the child zone. Of course, key rollover can also be done manually by
+ administrators.
+
+ This document describes the requirements for a protocol to perform
+ the automated key rollover process and focusses on interaction
+ between parent and child zone.
+
+2. The Key Rollover Process
+
+ Key rollover consists of renewing the DNSSEC keys used to sign
+ resource records in a given DNS zone file. There are two types of
+ rollover, ZSK rollovers and KSK rollovers.
+
+ During a ZSK rollover, all changes are local to the zone that renews
+ its key: there is no need to contact other zones administrators to
+ propagate the performed changes because a ZSK has no associated DS
+ record in the parent zone.
+
+ During a KSK rollover, new DS RR(s) must be created and stored in the
+ parent zone. In consequence, data must be exchanged between child
+ and parent zones.
+
+ The key rollover is built from two parts of different nature:
+ o An algorithm that generates new keys and signs the zone file. It
+ can be local to the zone,
+ o the interaction between parent and child zones.
+
+ One example of manual key rollover [3] is:
+ o The child zone creates a new KSK,
+
+
+Guette & Courtay Expires July 19, 2005 [Page 3]
+Internet-Draft Automated Rollover Requirements January 2005
+
+ o the child zone waits for the creation of the DS RR in its parent
+ zone,
+ o the child zone deletes the old key,
+ o the parent zone deletes the old DS RR.
+
+ This document concentrates on defining interactions between entities
+ present in key rollover process.
+
+3. Basic Requirements
+
+ This section provides the requirements for automated key rollover in
+ case of normal use. Exceptional case like emergency rollover is
+ specifically described later in this document.
+
+ The main condition during a key rollover is that the chain of trust
+ must be preserved to every validating DNS client. No matter if this
+ client retrieves some of the RRs from recursive caching name server
+ or from the authoritative servers for the zone involved in the
+ rollover.
+
+ Automated key rollover solution may be interrupted by a manual
+ intervention. This manual intervention should not compromise the
+ security state of the chain of trust. If the chain is safe before
+ the manual intervention, the chain of trust must remain safe during
+ and after the manual intervention
+
+ Two entities act during a KSK rollover: the child zone and its parent
+ zone. These zones are generally managed by different administrators.
+ These administrators should agree on some parameters like
+ availability of automated rollover, the maximum delay between
+ notification of changes in the child zone and the resigning of the
+ parent zone. The child zone needs to know this delay to schedule its
+ changes and/or to verify that the changes had been taken into account
+ in the parent zone. Hence, the child zone can also avoid some
+ critical cases where all child key are changed prior to the DS RR
+ creation.
+
+ By keeping some resource records during a given time, the recursive
+ cache servers can act on the automated rollover. The existence of
+ recursive cache servers must be taken into account by automated
+ rollover solution.
+
+ Indeed, during an automated key rollover a name server could have to
+ retrieve some DNSSEC data. An automated key rollover solution must
+ ensure that these data are not old DNSSEC material retrieved from a
+ recursive name server.
+
+
+
+Guette & Courtay Expires July 19, 2005 [Page 4]
+Internet-Draft Automated Rollover Requirements January 2005
+
+4. Messages authentication and information exchanged
+
+ This section addresses in-band rollover, security of out-of-band
+ mechanisms is out of scope of this document.
+
+ The security provided by DNSSEC must not be compromised by the key
+ rollover, thus every exchanged message must be authenticated to avoid
+ fake rollover messages from malicious parties.
+
+ Once the changes related to a KSK are made in a child zone, there are
+ two ways for the parent zone to take this changes into account:
+ o the child zone notify directly or not directly its parent zone in
+ order to create the new DS RR and store this DS RR in parent zone
+ file,
+ o or the parent zone poll the child zone.
+
+ In both cases, the parent zone must receive all the child keys that
+ need the creation of associated DS RRs in the parent zone.
+
+ Because errors could occur during the transmission of keys between
+ child and parent, the key exchange protocol must be fault tolerant.
+ Should an error occured during the automated key rollover, an
+ automated key rollover solution must be able to keep the zone files
+ in a consistent state.
+
+5. Emergency Rollover
+
+ Emergency key rollover is a special case of rollover decided by the
+ zone administrator generally for security reasons. In consequence,
+ emergency key rollover can break some of the requirement described
+ above.
+
+ A zone key might be compromised and an attacker can use the
+ compromised key to create and sign fake records. To avoid this, the
+ zone administrator may change the compromised key or all its keys as
+ soon as possible, without waiting for the creation of new DS RRs in
+ its parent zone.
+
+ Fast changes may break the chain of trust. The part of DNS tree
+ having this zone as apex can become unverifiable, but the break of
+ the chain of trust is necessary if the administrator wants to prevent
+ the compromised key from being used (to spoof DNS data).
+
+ Parent and child zones sharing an automated rollover mechanism,
+ should have an out-of-band way to re-establish a consistent state at
+ the delegation point (DS and DNSKEY RRs). This allows to avoid that
+ a malicious party uses the compromised key to roll the zone keys.
+
+
+Guette & Courtay Expires July 19, 2005 [Page 5]
+Internet-Draft Automated Rollover Requirements January 2005
+
+6. Security consideration
+
+ The automated key rollover process in DNSSEC allows automated renewal
+ of any kind of DNS key (ZSK or KSK). It is essential that parent
+ side and child side can do mutual authentication. Moreover,
+ integrity of the material exchanged between the parent and child zone
+ must be provided to ensure the right DS are created.
+
+ As in any application using public key cryptography, in DNSSEC a key
+ may be compromised. What to do in such a case can be describe in the
+ zone local policy and can violate some requirements described in this
+ draft. The emergency rollover can break the chain of trust in order
+ to protect the zone against the use of the compromised key.
+
+7. Acknowledgments
+
+ The authors want to thank members of IDsA project for their
+ contribution to this document.
+
+8 Normative References
+
+ [1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+ RFC 3658, December 2003.
+
+ [2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
+ (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
+ RFC 3757, May 2004.
+
+ [3] Kolkman, O., "DNSSEC Operational Practices",
+ draft-ietf-dnsop-dnssec-operational-practice-01 (work in
+ progress), May 2004.
+
+ [4] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+ "Resource Records for the DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-records-11 (work in progress), October
+ 2004.
+
+ [6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+ "DNS Security Introduction and Requirements",
+ draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
+ 2004.
+
+ [7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
+ "Protocol Modifications for the DNS Security Extensions",
+ draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
+
+
+Guette & Courtay Expires July 19, 2005 [Page 6]
+Internet-Draft Automated Rollover Requirements January 2005
+
+ 2004.
+
+Authors' Addresses
+
+ Gilles Guette
+ IRISA / INRIA
+ Campus de Beaulieu
+ 35042 Rennes CEDEX
+ FR
+
+ EMail: gilles.guette@irisa.fr
+ URI: http://www.irisa.fr
+
+ Olivier Courtay
+ Thomson R&D
+ 1, avenue Belle Fontaine
+ 35510 Cesson S?vign? CEDEX
+ FR
+
+ EMail: olivier.courtay@thomson.net
+
+Appendix A. Documents details and changes
+
+ This section is to be removed by the RFC editor if and when the
+ document is published.
+
+ Section about NS RR rollover has been removed
+
+ Remarks from Samuel Weiler and Rip Loomis added
+
+ Clarification about in-band rollover and in emergency section
+
+ Section 3, details about recursive cache servers added
+
+
+
+
+
+
+
+
+Guette & Courtay Expires July 19, 2005 [Page 7]
+Internet-Draft Automated Rollover Requirements January 2005
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent
+ that it has made any effort to identify any such rights.
+ Information on the IETF's procedures with respect to rights in
+ IETF Documents can be found in BCP 78 and 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 which may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr.org.
+
+
+ Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005). 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.
+
+ Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+Guette & Courtay Expires July 19, 2005 [Page 8]
diff --git a/doc/draft/draft-ietf-dnsop-respsize-02.txt b/doc/draft/draft-ietf-dnsop-respsize-02.txt
new file mode 100644
index 0000000..63fe2de
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-respsize-02.txt
@@ -0,0 +1,480 @@
+
+
+
+
+
+
+ DNSOP Working Group Paul Vixie, ISC
+ INTERNET-DRAFT Akira Kato, WIDE
+ <draft-ietf-dnsop-respsize-02.txt> July 2005
+
+ DNS 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 (2005). 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.
+
+
+
+
+
+
+ Expires December 2005 [Page 1]
+
+ INTERNET-DRAFT July 2005 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 UDP
+ reassembly limit for IPv4, it is a hard DNS protocol limit and is not
+ implicitly relaxed by changes in transport, for example to IPv6.
+
+ 1.2. The EDNS0 standard (see [RFC2671 2.3, 4.5]) permits larger
+ responses by mutual agreement of the requestor and responder. However,
+ deployment of EDNS0 cannot be expected to reach every Internet resolver
+ in the short or medium term. The 512 octet message size limit remains
+ in practical effect at this time.
+
+ 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.
+ For negative responses, there is rarely a space constraint. For
+ positive and delegation responses, though, every octet must be carefully
+ and sparingly allocated. This document specifically addresses
+ delegation response sizes.
+
+ 2 - Delegation Details
+
+ 2.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)
+ Authority Section: NS RRset (nameserver names)
+ Additional Section: A and AAAA RRsets (nameserver addresses)
+
+ 2.2. If the total response size would exceed 512 octets, and if the data
+ that would not fit belonged in the question, answer, or authority
+ section, then the TC bit will be set (indicating truncation) which may
+ cause the requestor to retry using TCP, depending on what information
+ was desired and what information was omitted. 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 protocol requirement that UDP be attempted
+ before falling back to TCP.)
+
+ 2.3. RRsets are never sent partially unless truncation occurs, in which
+ case the final apparent RRset in the final nonempty section must be
+ considered "possibly damaged". With or without truncation, the glue
+ present in the additional data section should be considered "possibly
+ incomplete", and requestors should be prepared to re-query for any
+ damaged or missing RRsets. For multi-transport name or mail services,
+
+
+
+ Expires December 2005 [Page 2]
+
+ INTERNET-DRAFT July 2005 RESPSIZE
+
+
+ this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A)
+ RRset is present.
+
+ 2.4. 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. If all nameserver names
+ in a message are similar (for example, all ending in ".ROOT-
+ SERVERS.NET"), then more space will be available for uncompressable data
+ (such as nameserver addresses).
+
+ 2.5. The query name can be as long as 255 characters of presentation
+ data, which can be up to 256 octets of network data. In this worst case
+ scenario, the question section will be 260 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.6. 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. For cost and performance
+ reasons, the majority of requests should be satisfied without truncation
+ or TCP retry.
+
+ 2.7. Requestors who deliberately send large queries to force truncation
+ are only increasing their own costs, and cannot effectively attack the
+ resources of an authority server since the requestor would have to retry
+ using TCP to complete the attack. An attack that always used TCP would
+ have a lower cost.
+
+ 2.8. The minimum useful number of address records is two, since with
+ only one address, the probability that it would refer to an unreachable
+ server is too high. Truncation which occurs after two address records
+ have been added to the additional data section is therefore less
+ operationally significant than truncation which occurs earlier.
+
+ 2.9. The best case is no truncation. This is because many requestors
+ will retry using TCP by reflex, or will automatically re-query for
+ RRsets that are "possibly truncated", without considering whether the
+ omitted data was actually necessary.
+
+ 2.10. Each added NS RR for a zone will add a minimum of between 16 and
+ 44 octets to every untruncated referral or negative response from the
+ zone's authority servers (16 octets for an NS RR, 16 octets for an A RR,
+ and 28 octets for an AAAA RR), in addition to whatever space is taken by
+ the nameserver name (NS NSDNAME and A/AAAA owner name).
+
+
+
+
+ Expires December 2005 [Page 3]
+
+ INTERNET-DRAFT July 2005 RESPSIZE
+
+
+ 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
+
+ ;; 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
+
+
+
+
+
+ Expires December 2005 [Page 4]
+
+ INTERNET-DRAFT July 2005 RESPSIZE
+
+
+ 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. 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):
+ if only A is considered: # of A is 4 (green)
+ if A and AAAA are condered: # of A+AAAA is 3 (yellow)
+ if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
+ For average size query (64 byte):
+ if only A is considered: # of A is 4 (green)
+ if A and AAAA are condered: # of A+AAAA is 4 (green)
+ if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
+
+ % 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):
+ if only A is considered: # of A is 4 (green)
+ if A and AAAA are condered: # of A+AAAA is 3 (yellow)
+ if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
+ For average size query (64 byte):
+ if only A is considered: # of A is 4 (green)
+ if A and AAAA are condered: # of A+AAAA is 4 (green)
+ if prefer_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
+ "orange" if two or more could fit, or "red" if fewer than two 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.
+
+
+
+
+ Expires December 2005 [Page 5]
+
+ INTERNET-DRAFT July 2005 RESPSIZE
+
+
+ We're assuming an average query name size of 64 since that is the
+ typical average maximum 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. (Note that in this case it is wise to serve the
+ common parent domain's zone from the same servers that are named within
+ it, in order to limit external dependencies when all your eggs are in a
+ single basket.)
+
+ 4.2. Thirteen (13) seems to be the effective maximum number of
+ nameserver names usable traditional (non-extended) DNS, assuming a
+ common parent domain name, and given that response truncation is
+ undesirable as an average case, and assuming mostly IPv4-only
+ reachability (only A RRs exist, not AAAA RRs).
+
+ 4.3. Adding two to five IPv6 nameserver address records (AAAA RRs) to a
+ prototypical delegation that currently contains thirteen (13) IPv4
+ nameserver addresses (A RRs) for thirteen (13) nameserver names under a
+ common parent, would not have a significant negative operational impact
+ on the domain name system.
+
+ 5 - Source Code
+
+ #!/usr/bin/perl
+ #
+ # SYNOPSIS
+ # repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
+ # if all queries are assumed to have zone suffux, such as "jp" in
+ # JP TLD servers, specify it in -z option
+ #
+ use strict;
+ use Getopt::Std;
+ 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;
+
+
+
+
+ Expires December 2005 [Page 6]
+
+ INTERNET-DRAFT July 2005 RESPSIZE
+
+
+ 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);
+ $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 "if only A is considered: ";
+ printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
+ printf "if A and AAAA are condered: ";
+ printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
+
+
+
+ Expires December 2005 [Page 7]
+
+ INTERNET-DRAFT July 2005 RESPSIZE
+
+
+ printf "if prefer_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;
+ }
+
+ Security Considerations
+
+ The recommendations contained in this document have no known security
+ implications.
+
+ IANA Considerations
+
+ This document does not call for changes or additions to any IANA
+ registry.
+
+ IPR Statement
+
+ Copyright (C) The Internet Society (2005). 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.
+
+
+
+
+
+ Expires December 2005 [Page 8]
+
+ INTERNET-DRAFT July 2005 RESPSIZE
+
+
+ Authors' Addresses
+
+ Paul Vixie
+ 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 December 2005 [Page 9]
+
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-dnsop-serverid-06.txt b/doc/draft/draft-ietf-dnsop-serverid-06.txt
new file mode 100644
index 0000000..c6ec7e4
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-serverid-06.txt
@@ -0,0 +1,618 @@
+
+
+
+
+Network Working Group S. Woolf
+Internet-Draft Internet Systems Consortium, Inc.
+Expires: September 6, 2006 D. Conrad
+ Nominum, Inc.
+ March 5, 2006
+
+
+ Requirements for a Mechanism Identifying a Name Server Instance
+ draft-ietf-dnsop-serverid-06
+
+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 September 6, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ With the increased use of DNS anycast, load balancing, and other
+ mechanisms allowing more than one DNS name server to share a single
+ IP address, it is sometimes difficult to tell which of a pool of name
+ servers has answered a particular query. A standardized mechanism to
+ determine the identity of a name server responding to a particular
+ query would be useful, particularly as a diagnostic aid for
+ administrators. Existing ad hoc mechanisms for addressing this need
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 1]
+
+Internet-Draft Serverid March 2006
+
+
+ have some shortcomings, not the least of which is the lack of prior
+ analysis of exactly how such a mechanism should be designed and
+ deployed. This document describes the existing convention used in
+ some widely deployed implementations of the DNS protocol, including
+ advantages and disadvantages, and discusses some attributes of an
+ improved mechanism.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 2]
+
+Internet-Draft Serverid March 2006
+
+
+1. Introduction and Rationale
+
+ Identifying which name server is responding to queries is often
+ useful, particularly in attempting to diagnose name server
+ difficulties. This is most obviously useful for authoritative
+ nameservers in the attempt to diagnose the source or prevalence of
+ inaccurate data, but can also conceivably be useful for caching
+ resolvers in similar and other situations. Furthermore, the ability
+ to identify which server is responding to a query has become more
+ useful as DNS has become more critical to more Internet users, and as
+ network and server deployment topologies have become more complex.
+
+ The traditional means for determining which of several possible
+ servers is answering a query has traditionally been based on the use
+ of the server's IP address as a unique identifier. However, the
+ modern Internet has seen the deployment of various load balancing,
+ fault-tolerance, or attack-resistance schemes such as shared use of
+ unicast IP addresses as documented in [RFC3258]. An unfortunate side
+ effect of these schemes has been to make the use of IP addresses as
+ identifiers somewhat problematic. Specifically, a dedicated DNS
+ query may not go to the same server as answered a previous query,
+ even though sent to the same IP address. Non-DNS methods such as
+ ICMP ping, TCP connections, or non-DNS UDP packets (such as those
+ generated by tools like "traceroute"), etc., may well be even less
+ certain to reach the same server as the one which receives the DNS
+ queries.
+
+ There is a well-known and frequently-used technique for determining
+ an identity for a nameserver more specific than the possibly-non-
+ unique "server that answered the query I sent to IP address XXX".
+ The widespread use of the existing convention suggests a need for a
+ documented, interoperable means of querying the identity of a
+ nameserver that may be part of an anycast or load-balancing cluster.
+ At the same time, however, it also has some drawbacks that argue
+ against standardizing it as it's been practiced so far.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 3]
+
+Internet-Draft Serverid March 2006
+
+
+2. Existing Conventions
+
+ For some time, the commonly deployed Berkeley Internet Name Domain
+ implementation of the DNS protocol suite from the Internet Systems
+ Consortium [BIND] has supported a way of identifying a particular
+ server via the use of a standards-compliant, if somewhat unusual, DNS
+ query. Specifically, a query to a recent BIND server for a TXT
+ resource record in class 3 (CHAOS) for the domain name
+ "HOSTNAME.BIND." will return a string that can be configured by the
+ name server administrator to provide a unique identifier for the
+ responding server. (The value defaults to the result of a
+ gethostname() call). This mechanism, which is an extension of the
+ BIND convention of using CHAOS class TXT RR queries to sub-domains of
+ the "BIND." domain for version information, has been copied by
+ several name server vendors.
+
+ A refinement to the BIND-based mechanism, which dropped the
+ implementation-specific string, replaces ".BIND" with ".SERVER".
+ Thus the query string to learn the unique name of a server may be
+ queried as "ID.SERVER".
+
+ (For reference, the other well-known name used by recent versions of
+ BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
+ query for a CHAOS TXT RR for this name will return an
+ administratively defined string which defaults to the version of the
+ server responding. This is, however, not generally implemented by
+ other vendors.)
+
+2.1. Advantages
+
+ There are several valuable attributes to this mechanism, which
+ account for its usefulness.
+
+ 1. The "HOSTNAME.BIND" or "ID.SERVER" query response mechanism is
+ within the DNS protocol itself. An identification mechanism that
+ relies on the DNS protocol is more likely to be successful
+ (although not guaranteed) in going to the same system as a
+ "normal" DNS query.
+
+ 2. Since the identity information is requested and returned within
+ the DNS protocol, it doesn't require allowing any other query
+ mechanism to the server, such as holes in firewalls for
+ otherwise-unallowed ICMP Echo requests. Thus it is likely to
+ reach the same server over a path subject to the same routing,
+ resource, and security policy as the query, without any special
+ exceptions to site security policy.
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 4]
+
+Internet-Draft Serverid March 2006
+
+
+ 3. It is simple to configure. An administrator can easily turn on
+ this feature and control the results of the relevant query.
+
+ 4. It allows the administrator complete control of what information
+ is given out in the response, minimizing passive leakage of
+ implementation or configuration details. Such details are often
+ considered sensitive by infrastructure operators.
+
+ 5. Hypothetically, since it's an ordinary DNS record and the
+ relevant DNSSEC RRs are class independent, the id.server response
+ RR could be signed, which has the advantages described in
+ [RFC4033].
+
+2.2. Disadvantages
+
+ At the same time, there are some serious drawbacks to the CHAOS/TXT
+ query mechanism that argue against standardizing it as it currently
+ operates.
+
+ 1. It requires an additional query to correlate between the answer
+ to a DNS query under normal conditions and the supposed identity
+ of the server receiving the query. There are a number of
+ situations in which this simply isn't reliable.
+
+ 2. It reserves an entire class in the DNS (CHAOS) for what amounts
+ to one zone. While CHAOS class is defined in [RFC1034] and
+ [RFC1035], it's not clear that supporting it solely for this
+ purpose is a good use of the namespace or of implementation
+ effort.
+
+ 3. The initial and still common form, using .BIND, is implementation
+ specific. BIND is one DNS implementation. At the time of this
+ writing, it is probably the most prevalent for authoritative
+ servers. This does not justify standardizing on its ad hoc
+ solution to a problem shared across many operators and
+ implementors. Meanwhile, the proposed refinement changes the
+ string but preserves the ad hoc CHAOS/TXT mechanism.
+
+ 4. There is no convention or shared understanding of what
+ information an answer to such a query for a server identity could
+ or should include, including a possible encoding or
+ authentication mechanism.
+
+ The first of the listed disadvantages may be technically the most
+ serious. It argues for an attempt to design a good answer to the
+ problem that "I need to know what nameserver is answering my
+ queries", not simply a convenient one.
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 5]
+
+Internet-Draft Serverid March 2006
+
+
+2.3. Characteristics of an Implementation Neutral Convention
+
+ The discussion above of advantages and disadvantages to the
+ HOSTNAME.BIND mechanism suggest some requirements for a better
+ solution to the server identification problem. These are summarized
+ here as guidelines for any effort to provide appropriate protocol
+ extensions:
+
+ 1. The mechanism adopted must be in-band for the DNS protocol. That
+ is, it needs to allow the query for the server's identifying
+ information to be part of a normal, operational query. It should
+ also permit a separate, dedicated query for the server's
+ identifying information. But it should preserve the ability of
+ the CHAOS/TXT query-based mechanism to work through firewalls and
+ in other situations where only DNS can be relied upon to reach
+ the server of interest.
+
+ 2. The new mechanism should not require dedicated namespaces or
+ other reserved values outside of the existing protocol mechanisms
+ for these, i.e. the OPT pseudo-RR. In particular, it should not
+ propagate the existing drawback of requiring support for a CLASS
+ and top level domain in the authoritative server (or the querying
+ tool) to be useful.
+
+ 3. Support for the identification functionality should be easy to
+ implement and easy to enable. It must be easy to disable and
+ should lend itself to access controls on who can query for it.
+
+ 4. It should be possible to return a unique identifier for a server
+ without requiring the exposure of information that may be non-
+ public and considered sensitive by the operator, such as a
+ hostname or unicast IP address maintained for administrative
+ purposes.
+
+ 5. It should be possible to authenticate the received data by some
+ mechanism analogous to those provided by DNSSEC. In this
+ context, the need could be met by including encryption options in
+ the specification of a new mechanism.
+
+ 6. The identification mechanism should not be implementation-
+ specific.
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 6]
+
+Internet-Draft Serverid March 2006
+
+
+3. IANA Considerations
+
+ This document proposes no specific IANA action. Protocol extensions,
+ if any, to meet the requirements described are out of scope for this
+ document. A proposed extension, specified and adopted by normal IETF
+ process, is described in [NSID], including relevant IANA action.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 7]
+
+Internet-Draft Serverid March 2006
+
+
+4. Security Considerations
+
+ Providing identifying information as to which server is responding to
+ a particular query from a particular location in the Internet can be
+ seen as information leakage and thus a security risk. This motivates
+ the suggestion above that a new mechanism for server identification
+ allow the administrator to disable the functionality altogether or
+ partially restrict availability of the data. It also suggests that
+ the serverid data should not be readily correlated with a hostname or
+ unicast IP address that may be considered private to the nameserver
+ operator's management infrastructure.
+
+ Propagation of protocol or service meta-data can sometimes expose the
+ application to denial of service or other attack. As DNS is a
+ critically important infrastructure service for the production
+ Internet, extra care needs to be taken against this risk for
+ designers, implementors, and operators of a new mechanism for server
+ identification.
+
+ Both authentication and confidentiality of serverid data are
+ potentially of interest to administrators-- that is, operators may
+ wish to make serverid data available and reliable to themselves and
+ their chosen associates only. This would imply both an ability to
+ authenticate it to themselves and keep it private from arbitrary
+ other parties. This led to Characteristics 4 and 5 of an improved
+ solution.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 8]
+
+Internet-Draft Serverid March 2006
+
+
+5. Acknowledgements
+
+ The technique for host identification documented here was initially
+ implemented by Paul Vixie of the Internet Software Consortium in the
+ Berkeley Internet Name Daemon package. Comments and questions on
+ earlier drafts were provided by Bob Halley, Brian Wellington, Andreas
+ Gustafsson, Ted Hardie, Chris Yarnell, Randy Bush, and members of the
+ ICANN Root Server System Advisory Committee. The newest version
+ takes a significantly different direction from previous versions,
+ owing to discussion among contributors to the DNSOP working group and
+ others, particularly Olafur Gudmundsson, Ed Lewis, Bill Manning, Sam
+ Weiler, and Rob Austein.
+
+6. References
+
+ [1] Mockapetris, P., "Domain Names - Concepts and Facilities",
+ RFC 1034, STD 0013, November 1987.
+
+ [2] Mockapetris, P., "Domain Names - Implementation and
+ Specification", RFC 1035, STD 0013, November 1987.
+
+ [3] Hardie, T., "Distributing Authoritative Name Servers via Shared
+ Unicast Addresses", RFC 3258, April 2002.
+
+ [4] ISC, "BIND 9 Configuration Reference".
+
+ [5] Austein, S., "DNS Name Server Identifier Option (NSID)",
+ Internet Drafts http://www.ietf.org/internet-drafts/
+ draft-ietf-dnsext-nsid-01.txt, January 2006.
+
+ [6] Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
+ "DNS Security Introduction and Requirements", RFC 4033,
+ March 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 9]
+
+Internet-Draft Serverid March 2006
+
+
+Authors' Addresses
+
+ Suzanne Woolf
+ Internet Systems Consortium, Inc.
+ 950 Charter Street
+ Redwood City, CA 94063
+ US
+
+ Phone: +1 650 423-1333
+ Email: woolf@isc.org
+ URI: http://www.isc.org/
+
+
+ David Conrad
+ Nominum, Inc.
+ 2385 Bay Road
+ Redwood City, CA 94063
+ US
+
+ Phone: +1 1 650 381 6003
+ Email: david.conrad@nominum.com
+ URI: http://www.nominum.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 10]
+
+Internet-Draft Serverid March 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.
+
+
+
+
+Woolf & Conrad Expires September 6, 2006 [Page 11]
+
+
diff --git a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
new file mode 100644
index 0000000..3353b3b
--- /dev/null
+++ b/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
@@ -0,0 +1,1588 @@
+
+ Mark Foster
+Internet Draft Tom McGarry
+Document: <draft-ietf-enum-e164-gstn-np-05.txt> James Yu
+ NeuStar, Inc.
+Category: Informational June 24, 2002
+
+
+ Number Portability in the GSTN: An Overview
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026 [RFC].
+
+ 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 (2002). All rights reserved.
+
+
+ Abstract
+
+ This document provides an overview of E.164 telephone number
+ portability (NP) in the Global Switched Telephone Network (GSTN).
+ NP is a regulatory imperative seeking to liberalize local telephony
+ service competition, by enabling end-users to retain telephone
+ numbers while changing service providers. NP changes the
+ fundamental nature of a dialed E.164 number from a hierarchical
+ physical routing address to a virtual address, thereby requiring the
+ transparent translation of the later to the former. In addition,
+ there are various regulatory constraints that establish relevant
+ parameters for NP implementation, most of which are not network
+ technology specific. Consequently, the implementation of NP
+ behavior consistent with applicable regulatory constraints, as well
+ as the need for interoperation with the existing GSTN NP
+ implementations, are relevant topics for numerous areas of IP
+ telephony work-in-progress at IETF.
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 1]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+
+ Table of Contents
+
+ 1. Introduction ............................................... 2
+ 2. Abbreviations and Acronyms ................................. 4
+ 3. Types of Number Portability ................................ 5
+ 4. Service Provider Number Portability Schemes ................ 7
+ 4.1 All Call Query (ACQ) .................................. 7
+ 4.2 Query on Release (QoR) ................................ 8
+ 4.3 Call Dropback ......................................... 9
+ 4.4 Onward Routing (OR) ................................... 9
+ 4.5 Comparisons of the Four Schemes ....................... 10
+ 5. Database Queries in the NP Environment ..................... 11
+ 5.1 U.S. and Canada ....................................... 12
+ 5.2 Europe ................................................ 13
+ 6. Call Routing in the NP Environment ......................... 14
+ 6.1 U.S. and Canada ....................................... 14
+ 6.2 Europe ................................................ 15
+ 7. NP Implementations for Geographic E.164 Numbers ............ 17
+ 8. Number Conservation Method Enabled By NP ................... 20
+ 8.1 Block Pooling ......................................... 20
+ 8.2 ITN Pooling ........................................... 21
+ 9. Potential Implications ..................................... 21
+ 10. Security Considerations .................................... 24
+ 11. IANA Considerations ........................................ 24
+ 12. Normative References ....................................... 24
+ 13. Informative References ..................................... 25
+ 14. Acknowledgement ............................................ 25
+ 15. Authors� Addresses ......................................... 25
+
+
+
+1. Introduction
+
+ This document provides an overview of E.164 telephone number
+ portability in the Global Switched Telephone Network (GSTN). There
+ are considered to be three types of number portability (NP): service
+ provider portability (SPNP), location portability (not to be
+ confused with terminal mobility), and service portability.
+
+ Service provider portability (SPNP), the focus of the present draft,
+ is a regulatory imperative in many countries seeking to liberalize
+ telephony service competition, especially local service.
+ Historically, local telephony service (as compared to long distance
+ or international service) has been regulated as a utility-like form
+ of service. While a number of countries had begun liberalization
+ (e.g. privatization, de-regulation, or re-regulation) some years
+ ago, the advent of NP is relatively recent (since ~1995).
+
+ E.164 numbers can be non-geographic and geographic numbers. Non-
+ geographic numbers do not reveal the locations information of those
+ numbers. Geographic E.164 numbers were intentionally designed as
+ hierarchical routing addresses which could systematically be digit-
+ analyzed to ascertain the country, serving network provider, serving
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 2]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ end-office switch, and specific line of the called party. As such,
+ without NP a subscriber wishing to change service providers would
+ incur a number change as a consequence of being served off of a
+ different end-office switch operated by the new service provider.
+ The cost and convenience impact to the subscriber of changing
+ numbers is seen as barrier to competition. Hence NP has become
+ associated with GSTN infrastructure enhancements associated with a
+ competitive environment driven by regulatory directives.
+
+ Forms of SPNP have been deployed or are being deployed widely in the
+ GSTN in various parts of the world, including the U.S., Canada,
+ Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong).
+ Other regions, such as South America (e.g. Brazil) are actively
+ considering it.
+
+ Implementation of NP within a national telephony infrastructure
+ entails potentially significant changes to numbering administration,
+ network element signaling, call routing and processing, billing,
+ service management, and other functions.
+
+ NP changes the fundamental nature of a dialed E.164 number from a
+ hierarchical physical routing address to a virtual address. NP
+ implementations attempt to encapsulate the impacts to the GSTN and
+ make NP transparent to subscribers by incorporating a translation
+ function to map a dialed, potentially ported E.164 address, into a
+ network routing address (either a number prefix or another E.164
+ address) which can be hierarchically routed.
+
+ This is roughly analogous to the use of network address translation
+ on IP addresses to enable IP address portability by containing the
+ impact of the address change to the edge of the network and retain
+ the use of CIDR blocks in the core which can be route aggregated by
+ the network service provider to the rest of the internet.
+
+ NP bifurcates the historical role of a subscriber�s E.164 address
+ into two or more data elements (a dialed or virtual address, and a
+ network routing address) that must be made available to network
+ elements through an NP translations database, carried by forward
+ call signaling, and recorded on call detail records. Not only is
+ call processing and routing affected, but also so is SS7/C7
+ messaging. A number of TCAP-based SS7 messaging sets utilize an
+ E.164 address as an application-level network element address in the
+ global title address (GTA) field of the SCCP message header.
+ Consequently, SS7/C7 signaling transfer points (STPs) and gateways
+ need to be able to perform n-digit global title translation (GTT) to
+ translate a dialed E.164 address into its network address
+ counterpart via the NP database.
+
+ In addition, there are various national regulatory constraints that
+ establish relevant parameters for NP implementation, most of which
+ are not network technology specific. Consequently, implementations
+ of NP behavior in IP telephony consistent with applicable regulatory
+ constraints, as well as the need for interoperation with the
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 3]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ existing GSTN NP implementations, are relevant topics for numerous
+ areas of IP telephony work-in-progress at IETF.
+
+ This document describes three types of number portability and the
+ four schemes that have been standardized to support SPNP for
+ geographic E.164 numbersspecifically. Following that, specific
+ information regarding the call routing and database query
+ implementations are described for several regions (North American
+ and Europe) and industries (wireless vs. wireline). The Number
+ Portability Database (NPDB) interfaces and the call routing schemes
+ that are used in the North America and Europe are described to show
+ the variety of standards that may be implemented worldwide. A
+ glance of the NP implementations worldwide is provided. Number
+ pooling is briefly discussed to show how NP is being enhanced in the
+ U.S. to conserve North American area codes. The conclusion briefly
+ touches the potential impacts of NP on IP & Telecommunications
+ Interoperability. Appendix A provides some specific technical and
+ regulatory information on NP in North America. Appendix B describes
+ the number portability administration process that manages the
+ number portability database in North America.
+
+
+2. Abbreviations and Acronyms
+
+ ACQ All Call Query
+ AIN Advanced Intelligent Network
+ AMPS Advanced Mobile Phone System
+ ANSI American National Standards Institute
+ CDMA Code Division Multiple Access
+ CdPA Called Party Address
+ CdPN Called Party Number
+ CH Code Holder
+ CMIP Common Management Information Protocol
+ CS1 Capability Set 1
+ CS2 Capability Set 2
+ DN Directory Number
+ DNS Domain Name System
+ ETSI European Technical Standards Institute
+ FCI Forward Call Indicator
+ GAP Generic Address Parameter
+ GMSC Gateway Mobile Services Switching Center or Gateway Mobile
+ Switching Center
+ GSM Global System for Mobile Communications
+ GSTN Global Switched Telephone Network
+ GW Gateways
+ HLR Home Location Register
+ IAM Initial Address Message
+ IETF Internet Engineering Task Force
+ ILNP Interim LNP
+ IN Intelligent Network
+ INAP Intelligent Network Application Part
+ INP Interim NP
+ IP Internet Protocol
+ IS-41 Interim Standards Number 41
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 4]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ ISDN Integrated Services Digital Network
+ ISUP ISDN User Part
+ ITN Individual Telephony Number
+ ITU International Telecommunication Union
+ ITU-TS ITU-Telecommunication Sector
+ LDAP Lightweight Directory Access Protocol
+ LEC Local Exchange Carrier
+ LERG Local Exchange Routing Guide
+ LNP Local Number Portability
+ LRN Location Routing Number
+ MAP Mobile Application Part
+ MNP Mobile Number Portability
+ MSRN Mobile Station Roaming Number
+ MTP Message Transfer Part
+ NANP North American Numbering Plan
+ NP Number Portability
+ NPDB Number Portability Database
+ NRN Network Routing Number
+ OR Onward Routing
+ OSS Operation Support System
+ PCS Personal Communication Services
+ PNTI Ported Number Translation Indicator
+ PODP Public Office Dialing Plan
+ PUC Public Utility Commission
+ QoR Query on Release
+ RN Routing Number
+ RTP Return to Pivot
+ SCCP Signaling Connection Control Part
+ SCP Service Control Point
+ SIP Session Initiation Protocol
+ SMR Special Mobile Radio
+ SMS Service Management System
+ SPNP Service Provider Number Portability
+ SRF Signaling Relaying Function
+ SRI Send Routing Information
+ SS7 Signaling System Number 7
+ STP Signaling Transfer Point
+ TCAP Transaction Capabilities Application Part
+ TDMA Time Division Multiple Access
+ TN Telephone Number
+ TRIP Telephony Routing Information Protocol
+ URL Universal Resource Locator
+ U.S. United States
+
+
+3. Types of Number Portability
+
+ As there are several types of E.164 numbers (telephone numbers, or
+ just TN) in the GSTN, there are correspondingly several types of
+ E.164 NP in the GSTN. First there are so-call non-geographic E.164
+ numbers, commonly used for service-specific applications such as
+ freephone (800 or 0800). Portability of these numbers is called
+ non-geographic number portability (NGNP). NGNP, for example, was
+ deployed in the U.S. in 1986-92.
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 5]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+
+ Geographic number portability, which includes traditional fixed or
+ wireline numbers as well as mobile numbers which are allocated out
+ of geographic number range prefixes, is called NP or GNP or in the
+ U.S. local number portability (LNP).
+
+ Number portability allows the telephony subscribers in the Global
+ Switched Telephone Network (GSTN) to keep their phone numbers when
+ they change their service providers or subscribed services, or when
+ they move to a new location.
+
+ The ability to change the service provider while keeping the same
+ phone number is called service provider portability (SPNP) also
+ known as "operator portability."
+
+ The ability to change the subscriber�s fixed service location while
+ keeping the same phone number is called location portability.
+
+ The ability to change the subscribed services (e.g., from the plain
+ old telephone service to Integrated Services Digital Network (ISDN)
+ services) while keeping the same phone number is called service
+ portability. Another aspect of service portability is to allow the
+ subscribers to enjoy the subscribed services in the same way when
+ they roam outside their home networks as is supported by the
+ cellular/wireless networks.
+
+ In addition, mobile number portability (MNP) refers to specific NP
+ implementation in mobile networks either as part of a broader NP
+ implementation in the GSTN or on a stand-alone basis. Where
+ interoperation of LNP and MNP is supported, service portability
+ between fixed and mobile service types is possible.
+
+ At present, SPNP has been the primary form of NP deployed due to its
+ relevance in enabling local service competition.
+
+ Also in use in the GSTN are the terms interim NP (INP) or Interim
+ LNP (ILNP) and true NP. Interim NP usually refers to the use of
+ remote call forwarding-like measures to forward calls to ported
+ numbers through the donor network to the new service network. These
+ are considered interim relative to true NP, which seeks to remove
+ the donor network or old service provider from the call or signaling
+ path altogether. Often the distinction between interim and true NP
+ is a national regulatory matter relative to the
+ technical/operational requirements imposed on NP in that country.
+
+ Implementations of true NP in certain countries (e.g. U.S., Canada,
+ Spain, Belgium, Denmark) may pose specific requirements for IP
+ telephony implementations as a result of regulatory and industry
+ requirements for providing call routing and signaling independent of
+ the donor network or last previous serving network.
+
+
+
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 6]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+
+4. Service Provider Number Portability Schemes
+
+ Four schemes can be used to support service provider portability and
+ are briefly described below. But first, some further terms are
+ introduced.
+
+ The donor network is the network that first assigned a telephone
+ number (e.g., TN +1-202-533-1234) to a subscriber, out of a number
+ range administratively (e.g., +1 202-533) assigned to it. The
+ current service provider (new SP) or new serving network is the
+ network that currently serves the ported number. The old serving
+ network (or old SP) is the network that previously served the ported
+ number before the number was ported to the new serving network.
+ Since a TN can port a number of times, the old SP is not necessarily
+ the same as the donor network, except for the first time the TN
+ ports away, or if the TN ports back into the donor network and away
+ again. While the new SP and old SP roles are transitory as a TN
+ ports around, the donor network is always the same for any
+ particular TN based on the service provider to whom the subtending
+ number range was administratively assigned. See the discussion
+ below on number pooling, as this enhancement to NP further
+ bifurcates the role of donor network into two (the number range or
+ code holder network, and the block holder network).
+
+ To simplify the illustration, all the transit networks are ignored,
+ the originating or donor network is the one that performs the
+ database queries or call redirection, and the dialed directory
+ number (TN) has been ported out of the donor network before.
+
+ It is assumed that the old serving network, the new serving network
+ and the donor network are different networks so as to show which
+ networks are involved in call handling and routing and database
+ queries in each of four schemes. Please note that the port of the
+ number (process of moving it from one network to another) happened
+ prior to the call setup and is not included in the call steps.
+ Information carried in the signaling messages to support each of the
+ four schemes is not discussed to simplify the explanation.
+
+
+4.1 All Call Query (ACQ)
+
+ Figure 1 shows the call steps for the ACQ scheme. Those call steps
+ are as follows:
+
+ (1) The Originating Network receives a call from the caller and
+ sends a query to a centrally administered Number Portability
+ Database (NPDB), a copy of which is usually resident on a
+ network element within its network or through a third party
+ provider.
+ (2) The NPDB returns the routing number associated with the dialed
+ directory number. The routing number is discussed later in
+ Section 6.
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 7]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ (3) The Originating Network uses the routing number to route the
+ call to the new serving network.
+
+
+ +-------------+ +-----------+ Number +-----------+
+ | Centralized | | New Serv. | ported | Old Serv. |
+ | NPDB | +-------->| Network |<------------| Network |
+ +-------------+ | +-----------+ +-----------+
+ ^ | |
+ | | |
+ 1| | 3.|
+ | | 2. |
+ | | |
+ | v |
+ +----------+ | +----------+ +----------+
+ | Orig. |------+ | Donor | | Internal |
+ | Network | | Network | | NPDB |
+ +----------+ +----------+ +----------+
+
+
+ Figure 1 - All Call Query (ACQ) Scheme.
+
+
+4.2 Query on Release (QoR)
+
+ Figure 2 shows the call steps for the QoR scheme. Those call steps
+ are as follows:
+
+
+ +-------------+ +-----------+ Number +-----------+
+ | Centralized | | New Serv. | ported | Old Serv. |
+ | NPDB | | Network |<------------| Network |
+ +-------------+ +-----------+ +-----------+
+ ^ | ^
+ | | 4. |
+ 3.| | 5. |
+ | | +----------------------+
+ | | |
+ | v |
+ +----------+ 2. +----------+ +----------+
+ | Orig. |<---------------| Donor | | Internal |
+ | Network |--------------->| Network | | NPDB |
+ +----------+ 1. +----------+ +----------+
+
+
+ Figure 2 - Query on Release (QoR) Scheme.
+
+ (1) The Originating Network receives a call from the caller and
+ routes the call to the donor network.
+ (2) The donor network releases the call and indicates that the
+ dialed directory number has been ported out of that switch.
+ (3) The Originating Network sends a query to its copy of the
+ centrally administered NPDB.
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 8]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ (4) The NPDB returns the routing number associated with the dialed
+ directory number.
+ (5) The Originating Network uses the routing number to route the
+ call to the new serving network.
+
+
+4.3 Call Dropback
+
+ Figure 3 shows the call steps for the Dropback scheme. This scheme
+ is also known as "Return to Pivot (RTP)." Those call steps are as
+ follows:
+
+ (1) The Originating Network receives a call from the caller and
+ routes the call to the donor network.
+ (2) The donor network detects that the dialed directory number has
+ been ported out of the donor switch and checks with an internal
+ network-specific NPDB.
+ (3) The internal NPDB returns the routing number associated with the
+ dialed directory number.
+ (4) The donor network releases the call by providing the routing
+ number.
+ (5) The Originating Network uses the routing number to route the
+ call to the new serving network.
+
+ +-------------+ +-----------+ Number +-----------+
+ | Centralized | | New Serv. | porting | Old Serv. |
+ | NPDB | | Network |<------------| Network |
+ +-------------+ +-----------+ +-----------+
+ /\
+ |
+ 5. |
+ +------------------------+
+ |
+ |
+ +----------+ 4. +----------+ 3. +----------+
+ | Orig. |<---------------| Donor |<----------| Internal |
+ | Network |--------------->| Network |---------->| NPDB |
+ +----------+ 1. +----------+ 2. +----------+
+
+
+ Figure 3 - Dropback Scheme.
+
+
+4.4 Onward Routing (OR)
+
+ Figure 4 shows the call steps for the OR scheme. Those call steps
+ are as follows:
+
+ (1) The Originating Network receives a call from the caller and
+ routes the call to the donor network.
+ (2) The donor network detects that the dialed directory number has
+ been ported out of the donor switch and checks with an internal
+ network-specific NPDB.
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 9]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ (3) The internal NPDB returns the routing number associated with the
+ dialed directory number.
+ (4) The donor network uses the routing number to route the call to
+ the new serving network.
+
+
+ +-------------+ +-----------+ Number +-----------+
+ | Centralized | | New Serv. | porting | Old Serv. |
+ | NPDB | | Network |<------------| Network |
+ +-------------+ +-----------+ +-----------+
+ /\
+ |
+ 4.|
+ |
+ +----------+ +----------+ 3. +----------+
+ | Orig. | | Donor |<----------| Internal |
+ | Network |--------------->| Network |---------->| NPDB |
+ +----------+ 1. +----------+ 2. +----------+
+
+
+ Figure 4 - Onward Routing (OR) Scheme.
+
+4.5 Comparisons of the Four Schemes
+
+ Only the ACQ scheme does not involve the donor network when routing
+ the call to the new serving network of the dialed ported number.
+ The other three schemes involve call setup to or signaling with the
+ donor network.
+
+ Only the OR scheme requires the setup of two physical call segments,
+ one from the Originating Network to the donor network and the other
+ from the donor network to the new serving network. The OR scheme is
+ the least efficient in terms of using the network transmission
+ facilities. The QoR and Dropback schemes set up calls to the donor
+ network first but release the call back to the Originating Network
+ that then initiates a new call to the Current Serving Network. For
+ the QoR and Dropback schemes, circuits are still reserved one by one
+ between the Originating Network and the donor network when the
+ Originating Network sets up the call towards the donor network.
+ Those circuits are released one by one when the call is released
+ from the donor network back to the Originating Network. The ACQ
+ scheme is the most efficient in terms of using the switching and
+ transmission facilities for the call.
+
+ Both the ACQ and QoR schemes involve Centralized NPDBs for the
+ Originating Network to retrieve the routing information.
+ Centralized NPDB means that the NPDB contains ported number
+ information from multiple networks. This is in contrast to the
+ internal network-specific NPDB that is used for the Dropback and OR
+ schemes. The internal NPDB only contains information about the
+ numbers that were ported out of the donor network. The internal
+ NPDB can be a stand-alone database that contains information about
+ all or some ported-out numbers from the donor network. It can also
+ reside on the donor switch and only contains information about those
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 10]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ numbers ported out of the donor switch. In that case, no query to a
+ stand-alone internal NPDB is required. The donor switch for a
+ particular phone number is the switch to which the number range is
+ assigned from which that phone number was originally assigned.
+
+ For example, number ranges in the North American Numbering Plan
+ (NANP) are usually assigned in the form of central office codes (CO
+ codes) comprising a six-digit prefix formatted as a NPA+NXX. Thus a
+ switch serving +1-202-533 would typically serve +1-202-533-0000
+ through +1-202-533-9999. In major cities, switches usually host
+ several CO codes. NPA stands for Numbering Plan Area that is also
+ known as the area code. It is three-digit long and has the format
+ of NXX where N is any digit from 2 to 9 and X is any digit from 0 to
+ 9. NXX in the NPA+NXX format is known as the office code that has
+ the same format as the NPA. When a NPA+NXX code is set as
+ �portable� in the Local Exchange Routing Guide (LERG), it becomes a
+ "portable NPA+NXX" code.
+
+ Similarly, in other national E.164 numbering plans, number ranges
+ cover a contiguous range of numbers within that range. Once a
+ number within that range has ported away from the donor network, all
+ numbers in that range are considered potentially ported and should
+ be queried in the NPDB.
+
+ The ACQ scheme has two versions. One version is for the Originating
+ Network to always query the NPDB when a call is received from the
+ caller regardless whether the dialed directory number belongs to any
+ number range that is portable or has at least one number ported out.
+ The other version is to check whether the dialed directory number
+ belongs to any number range that is portable or has at least one
+ number ported out. If yes, an NPDB query is sent. If not, no NPDB
+ query is sent. The former performs better when there are many
+ portable number ranges. The latter performs better when there are
+ not too many portable number ranges at the expense of checking every
+ call to see whether NPDB query is needed. The latter ACQ scheme is
+ similar to the QoR scheme except that the QoR scheme uses call setup
+ and relies on the donor network to indicate "number ported out"
+ before launching the NPDB query.
+
+
+5. Database Queries in the NP Environment
+
+ As indicated earlier, the ACQ and QoR schemes require that a switch
+ query the NPDB for routing information. Various standards have been
+ defined for the switch-to-NPDB interface. Those interfaces with
+ their protocol stacks are briefly described below. The term "NPDB"
+ is used for a stand-alone database that may support just one or some
+ or all of the interfaces mentioned below. The NPDB query contains
+ the dialed directory number and the NPDB response contains the
+ routing number. There are certainly other information that is sent
+ in the query and response. The primary interest is to get the
+ routing number from the NPDB to the switch for call routing.
+
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 11]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+5.1 U.S. and Canada
+
+ One of the following five NPDB interfaces can be used to query an
+ NPDB:
+
+ (a) Advanced Intelligent Network (AIN) using the American National
+ Standards Institute (ANSI) version of the Intelligent Network
+ Application Part (INAP) [ANSI SS] [ANSI DB]. The INAP is
+ carried on top of the protocol stack that includes the (ANSI)
+ Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling
+ Connection Control Part (SCCP), and ANSI Transaction
+ Capabilities Application Part (TCAP). This interface can be
+ used by the wireline or wireless switches, is specific to the NP
+ implementation in North America, and is modeled on the Public
+ Office Dialing Plan (PODP) trigger defined in the Advanced
+ Intelligent Network (AIN) 0.1 call model.
+
+ (b) Intelligent Network (IN), which is similar to the one used for
+ querying the 800 databases. The IN protocol is carried on top
+ of the protocol stack that includes the ANSI MTP Levels 1
+ through 3, ANSI SCCP, and ANSI TCAP. This interface can be used
+ by the wireline or wireless switches.
+
+ (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the
+ protocol stack that includes the ANSI MTP Levels 1 through 3,
+ ANSI SCCP, and ANSI TCAP. This interface can be used by the IS-
+ 41 based cellular/Personal Communication Services (PCS) wireless
+ switches (e.g., AMPS, TDMA and CDMA). Cellular systems use
+ spectrum at 800 MHz range and PCS systems use spectrum at 1900
+ MHz range.
+
+ (d) Global System for Mobile Communication Mobile Application Part
+ (GSM MAP) [GSM], which is carried on top of the protocol stack
+ that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and
+ International Telecommunication Union - Telecommunication Sector
+ (ITU-TS) TCAP. It can be used by the PCS1900 wireless switches
+ that are based on the GSM technologies. GSM is a series of
+ wireless standards defined by the European Telecommunications
+ Standards Institute (ETSI).
+
+ (e) ISUP triggerless translation. NP translations are performed
+ transparently to the switching network by the signaling network
+ (e.g. Signaling Transfer Points (STPs) or signaling gateways).
+ ISUP IAM messages are examined to determine if the CdPN field
+ has already been translated, and if not, an NPDB query is
+ performed, and the appropriate parameters in the IAM message
+ modified to reflect the results of the translation. The
+ modified IAM message is forwarded by the signaling node on to
+ the designated DPC in a transparent manner to continue call
+ setup. The NPDB can be integrated with the signaling node or be
+ accessed via an API locally or by a query to a remote NPDB using
+ a proprietary protocol or the schemes described above.
+
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 12]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ Wireline switches have the choice of using either (a), (b), or (e).
+ IS-41 based wireless switches have the choice of using (a), (b),
+ (c), or (e). PCS1900 wireless switches have the choice of using
+ (a), (b), (d), or (e). In the United States, service provider
+ portability will be supported by both the wireline and wireless
+ systems, not only within the wireline or wireless domain but also
+ across the wireline/wireless boundary. However, this is not true in
+ Europe where service provider portability is usually supported only
+ within the wireline or wireless domain, not across the
+ wireline/wireless boundary due to explicit use of service-specific
+ number range prefixes. The reason is to avoid caller confusion
+ about the call charge. GSM systems in Europe are assigned
+ distinctive destination network codes, and the caller pays a higher
+ charge when calling a GSM directory number.
+
+
+5.2 Europe
+
+ One of the following two interfaces can be used to query an NPDB:
+
+ (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is
+ carried on top of the protocol stack that includes the ITU-TS
+ MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP.
+
+ (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is
+ carried on top of the protocol stack that includes the ITU-TS
+ MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP,
+ and ITU-TS TCAP.
+
+ Wireline switches have the choice of using either (a) or (b);
+ however, all the implementations in Europe so far are based on CS1.
+ As indicated earlier that number portability in Europe does not go
+ across the wireline/wireless boundary. The wireless switches can
+ also use (a) or (b) to query the NPDBs if those NPDBs contains
+ ported wireless directory numbers. The term "Mobile Number
+ Portability (MNP)" is used for the support of service provider
+ portability by the GSM networks in Europe.
+
+ In most, if not all, cases in Europe, the calls to the wireless
+ directory numbers are routed to the wireless donor network first.
+ Over there, an internal NPDB is queried to determine whether the
+ dialed wireless directory number has been ported out or not. In
+ this case, the interface to the internal NPDB is not subject to
+ standardization.
+
+ MNP in Europe can also be supported via MNP Signaling Relay Function
+ (MNP-SRF). Again, an internal NPDB or a database integrated at the
+ MNP-SRF is used to modify the SCCP Called Party Address parameter in
+ the GSM MAP messages so that they can be re-directed to the wireless
+ serving network. Call routing involving MNP will be explained in
+ Section 6.2.
+
+
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 13]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+6. Call Routing in the NP Environment
+
+ This section discusses the call routing after the routing
+ information has been retrieved either through an NPDB query or an
+ internal database lookup at the donor switch, or from the Integrated
+ Services Digital Network User Part (ISUP) signaling message (e.g.,
+ for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it
+ is the Originating Network that has the routing information and is
+ ready to route the call. For the OR scheme, it is the donor network
+ that has the routing information and is ready to route the call.
+
+ A number of triggering schemes may be employed that determine where
+ in the call path the NPDB query is performed. In the U.S. an �N-1�
+ policy is used, which essentially says that for domestic calls, the
+ originating local carriers performs the query, otherwise, the long
+ distance carrier is expected to. To ensure independence of the
+ actual trigger policy employed in any one carrier, forward call
+ signaling is used to flag that an NPDB query has already been
+ performed and to therefore suppress any subsequent NP triggers that
+ may be encountered in downstream switches, in downstream networks.
+ This allows the earliest able network in the call path to perform
+ the query without introducing additional costs and call setup delays
+ were redundant queries performed downstream.
+
+
+6.1 U.S. and Canada
+
+ In the U.S. and Canada, a ten-digit North American Numbering Plan
+ (NANP) number called Location Routing Number (LRN) is assigned to
+ every switch involved in NP. In the NANP, a switch is not reachable
+ unless it has a unique number range (CO code) assigned to it.
+ Consequently, the LRN for a switch is always assigned out of a CO
+ code that is assigned to that switch.
+
+ The LRN assigned to a switch currently serving a particular ported
+ telephone number is returned as the network routing address in the
+ NPDB response. The service portability scheme that was adopted in
+ the North America is very often referred to as the LRN scheme or
+ method.
+
+ LRN serves as a network address for terminating calls served off
+ that switch using ported numbers. The LRN is assigned by the switch
+ operator using any of the unique CO codes (NPA+NXX) assigned to that
+ switch. The LRN is considered a non-dialable address, as the same
+ 10-digit number value may be assigned to a line on that switch. A
+ switch may have more than one LRN.
+
+ During call routing/processing, a switch performs an NPDB query to
+ obtain the LRN associated with the dialed directory number. NPDB
+ queries are performed for all the dialed directory numbers whose
+ NPA+NXX codes are marked as portable NPA+NXX at that switch. When
+ formulating the ISUP Initial Address Message (IAM) to be sent to the
+ next switch, the switch puts the ten-digit LRN in the ISUP Called
+ Party Number (CdPN) parameter and the originally dialed directory
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 14]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ number in the ISUP Generic Address parameter (GAP). A new code in
+ the GAP was defined to indicate that the address information in the
+ GAP is the dialed directory number. A new bit in the ISUP Forward
+ Call Indicator (FCI) parameter, the Ported Number Translation
+ Indicator (PNTI) bit, is set to imply that NPDB query has already
+ been performed. All the switches in the downstream will not perform
+ the NPDB query if the PNTI bit is set.
+
+ When the terminating switch receives the IAM and sees the PNTI bit
+ in the FCI parameter set and its own LRN in the CdPN parameter, it
+ retrieves the originally dialed directory number from the GAP and
+ uses the dialed directory number to terminate the call.
+
+ A dialed directory number with a portable NPA+NXX does not imply
+ that directory number has been ported. The NPDBs currently do not
+ store records for non-ported directory numbers. In that case, the
+ NPDB will return the same dialed directory number instead of the
+ LRN. The switch will then set the PNTI bit but keep the dialed
+ directory number in the CdPN parameter.
+
+ In the real world environment, the Originating Network is not always
+ the one that performs the NPDB query. For example, it is usually
+ the long distance carriers that query the NPDBs for long distance
+ calls. In that case, the Originating Network operated by the local
+ exchange carrier (LEC) simply routes the call to the long distance
+ carrier that is to handle that call. A wireless network acting as
+ the Originating Network can also route the call to the
+ interconnected local exchange carrier network if it does not want to
+ support the NPDB interface at its mobile switches.
+
+
+6.2 Europe
+
+ In some European countries, a routing number is prefixed to the
+ dialed directory number. The ISUP CdPN parameter in the IAM will
+ contain the routing prefix and the dialed directory number. For
+ example, United Kingdom uses routing prefixes with the format of
+ 5XXXXX and Italy uses C600XXXXX as the routing prefix. The networks
+ use the information in the ISUP CdPN parameter to route the call to
+ the New/Current Serving Network.
+
+ The routing prefix can identify the Current Serving Network or the
+ Current Serving Switch of a ported number. For the former case,
+ another query to the "internal" NPDB at the Current Serving Network
+ is required to identify the Current Serving Switch before routing
+ the call to that switch. This shields the Current Serving Switch
+ information for a ported number from the other networks at the
+ expense of an additional NPDB query. Another routing number, may be
+ meaningful within the Current Serving Network, will replace the
+ previously prefixed routing number in the ISUP CdPN parameter. For
+ the latter case, the call is routed to the Current Serving Switch
+ without an additional NPDB query.
+
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 15]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ When the terminating switch receives the IAM and sees its own
+ routing prefix in the CdPN parameter, it retrieves the originally
+ dialed directory number after the routing prefix, and uses the
+ dialed directory number to terminate the call.
+
+ The call routing example described above shows one of the three
+ methods that can be used to transport the Directory Number (DN) and
+ the Routing Number (RN) in the ISUP IAM message. In addition, some
+ other information may be added/modified as is listed in the ETSI 302
+ 097 document [ETSIISUP], which is based on the ITU-T Recommendation
+ Q.769.1 [ITUISUP]. The three methods and the enhancements in the
+ ISUP to support number portability are briefly described below
+
+ (a) Two separate parameters with the CdPN parameter containing the
+ RN and a new Called Directory Number (CdDN) parameter containing
+ the DN. A new value for the Nature of Address (NOA) indicator in
+ the CdPN parameter is defined to indicate that the RN is in the
+ CdPN parameter. The switches use the CdPN parameter to route the
+ call as is done today.
+
+ (b) Two separate parameters with the CdPN parameter containing the
+ DN and a new Network Routing Number (NRN) parameter containing
+ the RN. This method requires that the switches use the NRN
+ parameter to route the call.
+
+ (c) Concatenated parameter with the CdPN parameter containing the RN
+ plus the DN. A new Nature of Address (NOA) indicator in the CdPN
+ parameter is defined to indicate that the RN is concatenated with
+ the DN in the CdPN parameter. Some countries may not use new NOA
+ value because the routing prefix does not overlap with the dialed
+ directory numbers. But if the routing prefix overlaps with the
+ dialed directory numbers, a new NOA value must be assigned. For
+ example, Spain uses "XXXXXX" as the routing prefix to identify
+ the new serving network and uses a new NOA value of 126.
+
+ There is also a network option to add a new ISUP parameter called
+ Number Portability Forwarding Information parameter. This parameter
+ has a four-bit Number Portability Status Indicator field that can
+ provide an indication whether number portability query is done for
+ the called directory number and whether the called directory number
+ is ported or not if the number portability query is done.
+
+ Please note that all those NP enhancements for a ported number can
+ only be used in the country that defined them. This is because
+ number portability is supported within a nation. Within each
+ nation, the telecommunications industry or the regulatory bodies can
+ decide which method or methods to use. Number portability related
+ parameters and coding are usually not passed across the national
+ boundaries unless the interconnection agreements allow that. For
+ example, a UK routing prefix can only be used in UK, and would cause
+ routing problem if it appears outside UK.
+
+
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 16]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ As indicated earlier, an originating wireless network can query the
+ NPDB and concatenate the RN with DN in the CdPN parameter and route
+ the call directly to the Current Serving Network.
+
+ If NPDBs do not contain information about the wireless directory
+ numbers, the call, originated from either a wireline or a wireless
+ network, will be routed to the Wireless donor network. Over there,
+ an internal NPDB is queried to retrieve the RN that then is
+ concatenated with the DN in the CdPN parameter.
+
+ There are several ways of realizing MNP. When MNP-SRF is supported,
+ the Gateway Mobile Services Switching Center (GMSC) at the wireless
+ donor network, when receiving a call from the wireline network, can
+ send the GSM MAP Send Routing Information (SRI) message to the MNP-
+ SRF. The MNP-SRF interrogates an internal or integrated NPDB for
+ the RN of the MNP-SRF of the wireless Current Serving Network and
+ prefixes the RN to the dialed wireless directory number in the
+ global title address information in the SCCP Called Party Address
+ (CdPA) parameter. This SRI message will be routed to the MNP-SRF of
+ the wireless Current Serving Network, which then responds with an
+ acknowledgement by providing the RN plus the dialed wireless
+ directory number as the Mobile Station Roaming Number (MSRN). The
+ GMSC of the wireless donor network formulates the ISUP IAM with the
+ RN plus the dialed wireless directory number in the CdPN parameter
+ and routes the call to the wireless Current Serving Network. A GMSC
+ of the wireless Current Serving Network receives the call and sends
+ an SRI message to the associated MNP-SRF where the global title
+ address information of the SCCP CdPA parameter contains only the
+ dialed wireless directory number. The MNP-SRF then replaces the
+ global title address information in the SCCP CdPA parameter with the
+ address information associated with a Home Location Register (HLR)
+ that hosts the dialed wireless directory number and forwards the
+ message to that HLR after verifying that the dialed wireless
+ directory number is a ported-in number. The HLR then returns an
+ acknowledgement by providing an MSRN for the GMSC to route the call
+ to the MSC that currently serves the mobile station that is
+ associated with the dialed wireless directory number. Please see
+ [MNP] for details and additional scenarios.
+
+
+7. NP Implementations for Geographic E.164 Numbers
+
+ This section shows the known SPNP implementations worldwide.
+
+ +-------------+----------------------------------------------------+
+ + Country + SPNP Implementation +
+ +-------------+----------------------------------------------------+
+ + Argentina + Analyzing operative viability now. Will determine +
+ + + whether portability should be made obligatory +
+ + + after a technical solution has been determined. +
+ +-------------+----------------------------------------------------+
+ + Australia + NP supported by wireline operators since 11/30/99. +
+ + + NP among wireless operators in March/April 2000, +
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 17]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ + + but may be delayed to 1Q01. The access provider +
+ + + or long distance provider has the obligation to +
+ + + route the call to the correct destination. The +
+ + + donor network is obligated to maintain and make +
+ + + available a register of numbers ported away from +
+ + + its network. Telstra uses onward routing via an +
+ + + on-switch solution. +
+ +-------------+----------------------------------------------------+
+ + Austria + Uses onward routing at the donor network. Routing +
+ + + prefix is "86xx" where "xx" identifies the +
+ + + recipient network. +
+ +-------------+----------------------------------------------------+
+ + Belgium + ACQ selected by the industry. Routing prefix is +
+ + + "Cxxxx" where "xxxx" identifies the recipient +
+ + + switch. Another routing prefix is "C00xx" with "xx"+
+ + + identifying the recipient network. Plan to use NOA+
+ + + to identify concatenated numbers and abandon the +
+ + + hexadecimal routing prefix. +
+ +-------------+----------------------------------------------------+
+ + Brazil + Considering NP for wireless users. +
+ +-------------+----------------------------------------------------+
+ + Chile + There has been discussions lately on NP. +
+ +-------------+----------------------------------------------------+
+ + Colombia + There was an Article 3.1 on NP to support NP prior +
+ + + to December 31, 1999 when NP became technically +
+ + + possible. Regulator has not yet issued regulations +
+ + + concerning this matter. +
+ +-------------+----------------------------------------------------+
+ + Denmark + Uses ACQ. Routing number not passed between +
+ + + operators; however, NOA is set to "112" to +
+ + + indicate "ported number." QoR can be used based +
+ + + on bilateral agreements. +
+ +-------------+----------------------------------------------------+
+ + Finland + Uses ACQ. Routing prefix is "1Dxxy" where "xxy" +
+ + + identifies the recipient network and service type. +
+ +-------------+----------------------------------------------------+
+ + France + Uses onward routing. Routing prefix is "Z0xxx" +
+ + + where "xxx" identifies the recipient switch. +
+ +-------------+----------------------------------------------------+
+ + Germany + The originating network needs to do necessary +
+ + + rerouting. Operators decide their own solution(s).+
+ + + Deutsche Telekom uses ACQ. Routing prefix is +
+ + + "Dxxx" where "xxx" identifies the recipient +
+ + + network. +
+ +-------------+----------------------------------------------------+
+ + Hong Kong + Recipient network informs other networks about +
+ + + ported-in numbers. Routing prefix is "14x" where +
+ + + "14x" identifies the recipient network, or a +
+ + + routing number of "4x" plus 7 or 8 digits is used +
+ + + where "4x" identifies the recipient network and +
+ + + the rest of digits identify the called party. +
+ +-------------+----------------------------------------------------+
+ + Ireland + Operators choose their own solution but use onward +
+ + + routing now. Routing prefix is "1750" as the intra-+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 18]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ + + network routing code (network-specific) and +
+ + + "1752xxx" to "1759xxx" for GNP where "xxx" +
+ + + identifies the recipient switch. +
+ +-------------+----------------------------------------------------+
+ + Italy + Uses onward routing. Routing prefix is "C600xxxxx" +
+ + + where "xxxxx" identifies the recipient switch. +
+ + + Telecom Italia uses IN solution and other operators+
+ + + use on-switch solution. +
+ +-------------+----------------------------------------------------+
+ + Japan + Uses onward routing. Donor switch uses IN to get +
+ + + routing number. +
+ +-------------+----------------------------------------------------+
+ + Mexico + NP is considered in the Telecom law; however, the +
+ + + regulator (Cofetel) or the new local entrants have +
+ + + started no initiatives on this process. +
+ +-------------+----------------------------------------------------+
+ + Netherlands + Operators decide NP scheme to use. Operators have +
+ + + chosen ACQ or QoR. KPN implemented IN solution +
+ + + similar to U.S. solution. Routing prefix is not +
+ + + passed between operators. +
+ +-------------+----------------------------------------------------+
+ + Norway + OR for short-term and ACQ for long-term. QoR is +
+ + + optional. Routing prefix can be "xxx" with NOA=8, +
+ + + or "142xx" with NOA=3 where "xxx" or "xx" +
+ + + identifies the recipient network. +
+ +------------ +----------------------------------------------------+
+ + Peru + Wireline NP may be supported in 2001. +
+ +-------------+----------------------------------------------------+
+ + Portugal + No NP today. +
+ +-------------+----------------------------------------------------+
+ + Spain + Uses ACQ. Telefonica uses QoR within its network. +
+ + + Routing prefix is "xxyyzz" where "xxyyzz" +
+ + + identifies the recipient network. NOA is set to +
+ + + 126. +
+ +-------------+----------------------------------------------------+
+ + Sweden + Standardized the ACQ but OR for operators without +
+ + + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" +
+ + + with NOA=3 where "xxx" identifies the recipient +
+ + + network. But operators decide NP scheme to use. +
+ + + Telia uses onward routing between operators. +
+ +-------------+----------------------------------------------------+
+ + Switzerland + Uses OR now and QoR in 2001. Routing prefix is +
+ + + "980xxx" where "xxx" identifies the recipient +
+ + + network. +
+ +-------------+----------------------------------------------------+
+ + UK + Uses onward routing. Routing prefix is "5xxxxx" +
+ + + where "xxxxx" identifies the recipient switch. NOA +
+ + + is 126. BT uses the dropback scheme in some parts +
+ + + of its network. +
+ +-------------+----------------------------------------------------+
+ + US + Uses ACQ. "Location Routing Number (LRN)" is used +
+ + + in the Called Party Number parameter. Called party+
+ + + number is carried in the Generic Address Parameter +
+ + + Use a PNTI indicator in the Forward Call Indicator +
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 19]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ + + parameter to indicate that NPDB dip has been +
+ + + performed. +
+ +-------------+----------------------------------------------------+
+
+
+8. Number Conservation Methods Enabled by NP
+
+ In addition to porting numbers NP provides the ability for number
+ administrators to assign numbering resources to operators in smaller
+ increments. Today it is common for numbering resources to be
+ assigned to telephone operators in a large block of consecutive
+ telephone numbers (TNs). For example, in North America each of
+ these blocks contains 10,000 TNs and is of the format NXX+0000 to
+ NXX+9999. Operators are assigned a specific NXX, or block. That
+ operator is referred to as the block holder. In that block there
+ are 10,000 TNs with line numbers ranging from 0000 to 9999.
+
+ Instead of assigning an entire block to the operator NP allows the
+ administrator to assign a sub-block or even an individual telephone
+ number. This is referred to as block pooling and individual
+ telephone number (ITN) pooling, respectively.
+
+
+8.1 Block Pooling
+
+ Block Pooling refers to the process whereby the number administrator
+ assigns a range of numbers defined by a logical sub-block of the
+ existing block. Using North America as an example, block pooling
+ would allow the administrator to assign sub-blocks of 1,000 TNs to
+ multiple operators. That is, NXX+0000 to NXX+0999 can be assigned
+ to operator A, NXX+1000 to NXX+1999 can be assigned to operator B,
+ NXX-2000 to 2999 can be assigned to operator C, etc. In this
+ example block pooling divides one block of 10,000 TNs into ten
+ blocks of 1,000 TNs.
+
+ Porting the sub-blocks from the block holder enables block pooling.
+ Using the example above operator A is the block holder, as well as,
+ the holder of the first sub-block, NXX+0000 to NXX+0999. The second
+ sub-block, NXX+1000 to NXX+1999, is ported from operator A to
+ operator B. The third sub-block, NXX+2000 to NXX+2999, is ported
+ from operator A to operator C, and so on. NP administrative
+ processes and call processing will enable proper and efficient
+ routing.
+
+ From a number administration and NP administration perspective block
+ pooling introduces a new concept, that of the sub-block holder.
+ Block pooling requires coordination between the number
+ administrator, the NP administrator, the block holder, and the sub-
+ block holder. Block pooling must be implemented in a manner that
+ allows for NP within the sub-blocks. Each TN can have a different
+ serving operator, sub-block holder, and block holder.
+
+
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 20]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+8.2 ITN Pooling
+
+ ITN pooling refers to the process whereby the number administrator
+ assigns individual telephone numbers to operators. Using the North
+ American example, one block of 10,000 TNs can be divided into 10,000
+ ITNs. ITN is more commonly deployed in freephone services.
+
+ In ITN the block is not assigned to an operator but to a central
+ administrator. The administrator then assigns ITNs to operators.
+ NP administrative processes and call processing will enable proper
+ and efficient routing.
+
+
+9. Potential Implications
+
+ There are three general areas of impact to IP telephony work-in-
+ progress at IETF:
+
+ - Interoperation between NP in GSTN and IP telephony
+ - NP implementation or emulation in IP telephony
+ - Interconnection to NP administrative environment
+
+ A good understanding of how number portability is supported in the
+ GSTN is important when addressing the interworking issues between
+ IP-based networks and the GSTN. This is especially important when
+ the IP-based network needs to route the calls to the GSTN. As shown
+ in Section 5, there are a variety of standards with various protocol
+ stacks for the switch-to-NPDB interface. Not only that, the
+ national variations of the protocol standards make it very
+ complicated to deal with in a global environment. If an entity in
+ the IP-based network needs to query those existing NPDBs for routing
+ number information to terminate the calls to the destination GSTN,
+ it would be impractical, if not an impossible, job for that entity
+ to support all those interface standards to access the NPDBs in many
+ countries.
+
+ Several alternatives may address this particular problem. One
+ alternative is to use certain entities in the IP-based networks for
+ dealing with NP query, similar to the International Switches that
+ are used in the GSTN to interwork different national ISUP
+ variations. This will force signaling information associated with
+ the calls to certain NP-capable networks in the terminating GSTN to
+ be routed to those IP entities that support the NP functions. Those
+ IP entities then query the NPDBs in the terminating country. This
+ will limit the number of NPDB interfaces that certain IP entities
+ need to support. Another alternative can be to define a "common"
+ interface to be supported by all the NPDBs so that all the IP
+ entities use that standardized protocol to query them. The
+ existing NPDBs can support this additional interface, or new NPDBs
+ can be deployed that contain the same information but support the
+ common IP interface. The candidates for such a common interface
+ include Lightweight Directory Access Protocol (LDAP) and SIP
+ [SIP](e.g., using the SIP redirection capability). Certainly
+
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 21]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ another possibility is to use interworking function to convert from
+ one protocol to another.
+
+ IP-based networks can handle the domestic calls between two GSTNs.
+ If the originating GSTN has performed NPDB query, SIP will need to
+ transport and make use of some of the ISUP signaling information
+ even if ISUP signaling may be encapsulated in SIP. Also, IP-based
+ networks may perform the NPDB queries, as the N-1 carrier. In that
+ case, SIP also needs to transport the NP related information while
+ the call is being routed to the destination GSTN. There are three
+ pieces of NP related information that SIP needs to transport. They
+ are 1) the called directory number, 2) a routing number, and 3) a
+ NPDB dip indicator. The NPDB dip indicator is needed so that the
+ terminating GSTN will not perform another NPDB dip. The routing
+ number is needed so that it is used to route the call to the
+ destination network or switch in the destination GSTN. The called
+ directory number is needed so that the terminating GSTN switch can
+ terminate the call. When the routing number is present, the NPDB
+ dip indicator may not be present because there are cases where
+ routing number is added for routing the call even if NP is not
+ involved. One issue is how to transport the NP related information
+ via SIP. The SIP Universal Resource Locator (URL) is one mechanism.
+ Another better choice may be to add an extension to the "tel" URL
+ [TEL] that is also supported by SIP. Please see [TELNP] for the
+ proposed extensions to the "tel" URL to support NP and freephone
+ service. Those extensions to the "tel" URL will be automatically
+ supported by SIP because they can be carried as the optional
+ parameters in the user portion of the "sip" URL.
+
+ For a called directory number that belongs to a country that
+ supports NP, and if the IP-based network is to perform the NPDB
+ query, the logical step is to perform the NPDB dip first to retrieve
+ the routing number and use that routing number to select the correct
+ IP telephony gateways that can reach the serving switch that serves
+ the called directory number. Therefore, if the "rn" parameter is
+ present in the "tel" URL or sip URL in the SIP INVITE message, it
+ instead of the called directory number should be used for making
+ routing decisions assuming that no other higher priority routing-
+ related parameters such as the �cic� are present. If "rn" is not
+ present, then the dialed directory number can be used as the routing
+ number for making routing decisions.
+
+ Telephony Routing Information Protocol (TRIP) [TRIP] is a policy
+ driven inter-administrative domain protocol for advertising the
+ reachability of telephony destinations between location servers, and
+ for advertising attributes of the routes to those destinations.
+ With the NP in mind, it is very important to know that it is the
+ routing number, if present, not the called directory number that
+ should be used to check against the TRIP tables for making the
+ routing decisions.
+
+ Overlap signaling exists in the GSTN today. For a call routing from
+ the originating GSTN to the IP-based network that involves overlap
+ signaling, NP will impact the call processing within the IP-based
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 22]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ networks if they must deal with the overlap signaling. The entities
+ in the IP-based networks that are to retrieve the NP information
+ (e.g., the routing number) must collect a complete called directory
+ number information before retrieving the NP information for a ported
+ number. Otherwise, the information retrieval won't be successful.
+ This is an issue for the IP-based networks if the originating GSTN
+ does not handle the overlap signaling by collecting the complete
+ called directory number.
+
+ The IETF enum working group is defining the use of Domain Name
+ System (DNS) for identifying available services associated with a
+ particular E.164 number [ENUM]. [ENUMPO] outlines the principles
+ for the operation of a telephone number service that resolves
+ telephone numbers into Internet domain name addresses and service-
+ specific directory discovery. [ENUMPO] implements a three-level
+ approach where the first level is the mapping of the telephone
+ number delegation tree to the authority to which the number has been
+ delegated, the second level is the provision of the requested DNS
+ resource records from a service registrar, and the third level is
+ the provision of service specific data from the service provider
+ itself. NP certainly must be considered at the first level because
+ the telephony service providers do not "own" or control the
+ telephone numbers under the NP environment; therefore, they may not
+ be the proper entities to have the authority for a given E.164
+ number. Not only that, there is a regulatory requirement on NP in
+ some countries that the donor network should not be relied on to
+ reach the delegated authority during the DNS process . The
+ delegated authority for a given E.164 number is likely to be an
+ entity designated by the end user that owns/controls a specific
+ telephone number or one that is designated by the service registrar.
+
+ Since the telephony service providers may have the need to use ENUM
+ for their network-related services (e.g., map an E.164 number to a
+ HLR Identifier in the wireless networks), their ENUM records must be
+ collocated with those of the telephony subscribers. If that is the
+ case, NP will impact ENUM when a telephony subscriber who has ENUM
+ service changes the telephony service provider. This is because
+ that the ENUM records from the new telephony service provider must
+ replace those from the old telephony service provider. To avoid the
+ NP impact on ENUM, it is recommended that the telephony service
+ providers use a different domain tree for their network-related
+ service. For example, if e164.arpa is chosen for �end user� ENUM, a
+ domain tree different from e164.arpa should be used for �carrier�
+ ENUM.
+
+ The IP-based networks also may need to support some forms of number
+ portability in the future if E.164 numbers [E164] are assigned to
+ the IP-based end users. One method is to assign a GSTN routing
+ number for each IP-based network domain or entity in a NP-capable
+ country. This may increase the number of digits in the routing
+ number to incorporate the IP entities and impact the existing
+ routing in the GSTN. Another method is to associate each IP entity
+ with a particular GSTN gateway. At that particular GSTN gateway,
+ the called directory number then is used to locate the IP-entity
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 23]
+
+Number Portability in the GSTN: An Overview June 24, 2002
+
+ that serves that dialed directory number. Yet, another method can
+ be to assign a special routing number so that the call to an end
+ user currently served by an IP entity is routed to the nearest GSTN
+ gateway. The called directory number then is used to locate the IP-
+ entity that serves that dialed directory number. A mechanism can be
+ developed or used for the IP-based network to locate the IP entity
+ that serves a particular dialed directory number. Many other types
+ of networks use E.164 numbers to identify the end users or terminals
+ in those networks. Number portability among GSTN, IP-based network
+ and those various types of networks may also need to be supported in
+ the future.
+
+
+10. Security Considerations
+
+ This document does not raise any security issues.
+
+
+11. IANA Considerations
+
+ This document introduces no new values for IANA registration.
+
+
+12. Normative References
+
+ [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability -
+ Operator Services Switching Systems," April 1999.
+
+ [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability -
+ Switching Systems," April 1999.
+
+ [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability
+ Database and Global Title Translation," April 1999.
+
+ [CS1] ITU-T Q-series Recommendations - Supplement 4, "Number
+ portability Capability set 1 requirements for service provider
+ portability (All call query and onward routing)," May 1998.
+
+ [CS2] ITU-T Q-series Recommendations - Supplement 5, "Number
+ portability -Capability set 2 requirements for service provider
+ portability (Query on release and Dropback)," March 1999.
+
+ [E164] ITU-T Recommendation E.164, "The International Public
+ Telecommunications Numbering Plan," 1997.
+
+ [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916.
+
+ [ETSIISUP] ETSI EN 302 097 V.1.2.2, �Integrated Services Digital
+ Network (ISDN); Signalling System No.7 (SS7); ISDN User Part
+ (ISUP); Enhancement for support of Number Portability (NP)
+ [ITU-T Recommendation Q.769.1 (2000), modified]
+
+ [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase
+ 2+); Mobile Application Part (MAP) specification".
+
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 24]
+
+Number Portability in the GSTN: An Overview March 1, 2002
+
+
+
+ [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for
+ Wireless Number Portability Phase II (December 1998)"Number
+ Portability Network Support," April 1998.
+
+ [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 -
+ ISDN User Part Enhancements for the Support of Number
+ Portability," December 1999.
+
+ [MNP] ETSI EN 301 716 (2000-10) European Standard
+ (Telecommunications series) Digital cellular telecommunications
+ system (Phase 2+); Support of Mobile Number Portability (MNP);
+ Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0
+ Release 1998).
+
+ [RFC] Scott Bradner, RFC2026, "The Internet Standards Process --
+ Revision 3," October 1996.
+
+
+13. Informative References
+
+ [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific
+ Provisioning: Principles of Operations," draft-ietf-enum-
+ operation-02.txt, February 23, 2001.
+
+ [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP:
+ Session Initiation Protocol," February 27, 2002.
+
+ [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis-
+ 04.txt, "URIs for Telephone Calls," May 24, 2002.
+
+ [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL
+ to support Number Portability and Freephone Service," June 14,
+ 2002.
+
+ [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony
+ Routing Information Protocol (TRIP)," January 2002.
+
+
+14. Acknowledgment
+
+ The authors would like to thank Monika Muench for providing
+ information on ISUP and MNP.
+
+
+15. Authors' Addresses
+
+ Mark D. Foster
+ NeuStar, Inc.
+ 1120 Vermont Avenue, NW,
+ Suite 400
+ Washington, D.C. 20005
+ United States
+
+Foster,McGarry,Yu Expired on August 31, 2002 [Page 25]
+
+Number Portability in the GSTN: An Overview March 1, 2002
+
+
+
+ Phone: +1-202-533-2800
+ Fax: +1-202-533-2987
+ Email: mark.foster@neustar.biz
+
+ Tom McGarry
+ NeuStar, Inc.
+ 1120 Vermont Avenue, NW,
+ Suite 400
+ Washington, D.C. 20005
+ United States
+
+ Phone: +1-202-533-2810
+ Fax: +1-202-533-2987
+ Email: tom.mcgarry@neustar.biz
+
+ James Yu
+ NeuStar, Inc.
+ 1120 Vermont Avenue, NW,
+ Suite 400
+ Washington, D.C. 20005
+ United States
+
+ Phone: +1-202-533-2814
+ Fax: +1-202-533-2987
+ Email: james.yu@neustar.biz
+
+
+
+Full Copyright Statement
+
+ "Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph
+ are included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+
+
+Foster,McGarry,Yu Expired on August 31, 2002 [Page 26]
+
+Number Portability in the GSTN: An Overview March 1, 2002
+
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Foster,McGarry,Yu Expired on August 31, 2002 [Page 27]
+
\ No newline at end of file
diff --git a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
new file mode 100644
index 0000000..2d5c87e
--- /dev/null
+++ b/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
@@ -0,0 +1,1200 @@
+
+
+
+
+
+
+IPv6 Working Group John Loughney (ed)
+Internet-Draft Nokia
+ January 14, 2004
+
+Expires: July 14, 2004
+
+
+
+ IPv6 Node Requirements
+ draft-ietf-ipv6-node-requirements-08.txt
+
+
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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 (2003). All Rights Reserved.
+
+Abstract
+
+ This document defines requirements for IPv6 nodes. It is expected
+ that IPv6 will be deployed in a wide range of devices and situations.
+ Specifying the requirements for IPv6 nodes allows IPv6 to function
+ well and interoperate in a large number of situations and
+ deployments.
+
+
+
+
+
+Loughney (editor) February 16, 2004 [Page 1]
+
+
+
+
+
+Internet-Draft
+
+
+Table of Contents
+
+ 1. Introduction
+ 1.1 Requirement Language
+ 1.2 Scope of this Document
+ 1.3 Description of IPv6 Nodes
+ 2. Abbreviations Used in This Document
+ 3. Sub-IP Layer
+ 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
+ 3.2 IP version 6 over PPP - RFC2472
+ 3.3 IPv6 over ATM Networks - RFC2492
+ 4. IP Layer
+ 4.1 Internet Protocol Version 6 - RFC2460
+ 4.2 Neighbor Discovery for IPv6 - RFC2461
+ 4.3 Path MTU Discovery & Packet Size
+ 4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
+ 4.5 Addressing
+ 4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
+ 5. Transport and DNS
+ 5.1 Transport Layer
+ 5.2 DNS
+ 5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+ 6. IPv4 Support and Transition
+ 6.1 Transition Mechanisms
+ 7. Mobility
+ 8. Security
+ 8.1 Basic Architecture
+ 8.2 Security Protocols
+ 8.3 Transforms and Algorithms
+ 8.4 Key Management Methods
+ 9. Router Functionality
+ 9.1 General
+ 10. Network Management
+ 10.1 MIBs
+ 11. Security Considerations
+ 12. References
+ 12.1 Normative
+ 12.2 Non-Normative
+ 13. Authors and Acknowledgements
+ 14. Editor's Address
+ Notices
+
+
+
+
+
+
+
+
+
+
+Loughney (editor) February 16, 2004 [Page 2]
+
+
+
+
+
+Internet-Draft
+
+
+1. Introduction
+
+ The goal of this document is to define the common functionality
+ required from both IPv6 hosts and routers. Many IPv6 nodes will
+ implement optional or additional features, but all IPv6 nodes can be
+ expected to implement the mandatory requirements listed in this
+ document.
+
+ This document tries to avoid discussion of protocol details, and
+ references RFCs for this purpose. In case of any conflicting text,
+ this document takes less precedence than the normative RFCs, unless
+ additional clarifying text is included in this document.
+
+ Although the document points to different specifications, it should
+ be noted that in most cases, the granularity of requirements are
+ smaller than a single specification, as many specifications define
+ multiple, independent pieces, some of which may not be mandatory.
+
+ As it is not always possible for an implementer to know the exact
+ usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
+ that they should adhere to Jon Postel's Robustness Principle:
+
+ Be conservative in what you do, be liberal in what you accept from
+ others [RFC-793].
+
+1.1 Requirement Language
+
+ 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 [RFC-2119].
+
+1.2 Scope of this Document
+
+ IPv6 covers many specifications. It is intended that IPv6 will be
+ deployed in many different situations and environments. Therefore,
+ it is important to develop the requirements for IPv6 nodes, in order
+ to ensure interoperability.
+
+ This document assumes that all IPv6 nodes meet the minimum
+ requirements specified here.
+
+1.3 Description of IPv6 Nodes
+
+ From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we
+ have the following definitions:
+
+ Description of an IPv6 Node
+
+
+
+
+Loughney (editor) February 16, 2004 [Page 3]
+
+
+
+
+
+Internet-Draft
+
+
+ - a device that implements IPv6
+
+ Description of an IPv6 router
+
+ - a node that forwards IPv6 packets not explicitly addressed to
+ itself.
+
+ Description of an IPv6 Host
+
+ - any node that is not a router.
+
+2. Abbreviations Used in This Document
+
+ ATM Asynchronous Transfer Mode
+
+ AH Authentication Header
+
+ DAD Duplicate Address Detection
+
+ ESP Encapsulating Security Payload
+
+ ICMP Internet Control Message Protocol
+
+ IKE Internet Key Exchange
+
+ MIB Management Information Base
+
+ MLD Multicast Listener Discovery
+
+ MTU Maximum Transfer Unit
+
+ NA Neighbor Advertisement
+
+ NBMA Non-Broadcast Multiple Access
+
+ ND Neighbor Discovery
+
+ NS Neighbor Solicitation
+
+ NUD Neighbor Unreachability Detection
+
+ PPP Point-to-Point Protocol
+
+ PVC Permanent Virtual Circuit
+
+ SVC Switched Virtual Circuit
+
+3. Sub-IP Layer
+
+
+
+Loughney (editor) February 16, 2004 [Page 4]
+
+
+
+
+
+Internet-Draft
+
+
+ An IPv6 node must include support for one or more IPv6 link-layer
+ specifications. Which link-layer specifications are included will
+ depend upon what link-layers are supported by the hardware available
+ on the system. It is possible for a conformant IPv6 node to support
+ IPv6 on some of its interfaces and not on others.
+
+ As IPv6 is run over new layer 2 technologies, it is expected that new
+ specifications will be issued. This section highlights some major
+ layer 2 technologies and is not intended to be complete.
+
+3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
+
+ Nodes supporting IPv6 over Ethernet interfaces MUST implement
+ Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
+
+3.2 IP version 6 over PPP - RFC2472
+
+ Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-
+ 2472].
+
+3.3 IPv6 over ATM Networks - RFC2492
+
+ Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
+ Networks [RFC-2492]. Additionally, RFC 2492 states:
+
+ A minimally conforming IPv6/ATM driver SHALL support the PVC mode
+ of operation. An IPv6/ATM driver that supports the full SVC mode
+ SHALL also support PVC mode of operation.
+
+4. IP Layer
+
+4.1 Internet Protocol Version 6 - RFC2460
+
+ The Internet Protocol Version 6 is specified in [RFC-2460]. This
+ specification MUST be supported.
+
+ Unrecognized options in Hop-by-Hop Options or Destination Options
+ extensions MUST be processed as described in RFC 2460.
+
+ The node MUST follow the packet transmission rules in RFC 2460.
+
+ Nodes MUST always be able to send, receive and process fragment
+ headers. All conformant IPv6 implementations MUST be capable of
+ sending and receving IPv6 packets; forwarding functionality MAY be
+ supported
+
+ RFC 2460 specifies extension headers and the processing for these
+ headers.
+
+
+
+Loughney (editor) February 16, 2004 [Page 5]
+
+
+
+
+
+Internet-Draft
+
+
+ A full implementation of IPv6 includes implementation of the
+ following extension headers: Hop-by-Hop Options, Routing (Type 0),
+ Fragment, Destination Options, Authentication and Encapsulating
+ Security Payload. [RFC-2460]
+
+ An IPv6 node MUST be able to process these headers. It should be
+ noted that there is some discussion about the use of Routing Headers
+ and possible security threats [IPv6-RH] caused by them.
+
+4.2 Neighbor Discovery for IPv6 - RFC2461
+
+ Neighbor Discovery SHOULD be supported. RFC 2461 states:
+
+ "Unless specified otherwise (in a document that covers operating
+ IP over a particular link type) this document applies to all link
+ types. However, because ND uses link-layer multicast for some of
+ its services, it is possible that on some link types (e.g., NBMA
+ links) alternative protocols or mechanisms to implement those
+ services will be specified (in the appropriate document covering
+ the operation of IP over a particular link type). The services
+ described in this document that are not directly dependent on
+ multicast, such as Redirects, Next-hop determination, Neighbor
+ Unreachability Detection, etc., are expected to be provided as
+ specified in this document. The details of how one uses ND on
+ NBMA links is an area for further study."
+
+ Some detailed analysis of Neighbor Discovery follows:
+
+ Router Discovery is how hosts locate routers that reside on an
+ attached link. Router Discovery MUST be supported for
+ implementations.
+
+ Prefix Discovery is how hosts discover the set of address prefixes
+ that define which destinations are on-link for an attached link.
+ Prefix discovery MUST be supported for implementations. Neighbor
+ Unreachability Detection (NUD) MUST be supported for all paths
+ between hosts and neighboring nodes. It is not required for paths
+ between routers. However, when a node receives a unicast Neighbor
+ Solicitation (NS) message (that may be a NUD's NS), the node MUST
+ respond to it (i.e. send a unicast Neighbor Advertisement).
+
+ Duplicate Address Detection MUST be supported on all links supporting
+ link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take
+ place on all unicast addresses).
+
+ A host implementation MUST support sending Router Solicitations.
+
+ Receiving and processing Router Advertisements MUST be supported for
+
+
+
+Loughney (editor) February 16, 2004 [Page 6]
+
+
+
+
+
+Internet-Draft
+
+
+ host implementations. The ability to understand specific Router
+ Advertisement options is dependent on supporting the specification
+ where the RA is specified.
+
+ Sending and Receiving Neighbor Solicitation (NS) and Neighbor
+ Advertisement (NA) MUST be supported. NS and NA messages are required
+ for Duplicate Address Detection (DAD).
+
+ Redirect functionality SHOULD be supported. If the node is a router,
+ Redirect functionality MUST be supported.
+
+4.3 Path MTU Discovery & Packet Size
+
+4.3.1 Path MTU Discovery - RFC1981
+
+ Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
+ implementations MAY choose to not support it and avoid large packets.
+ The rules in RFC 2460 MUST be followed for packet fragmentation and
+ reassembly.
+
+4.3.2 IPv6 Jumbograms - RFC2675
+
+ IPv6 Jumbograms [RFC-2675] MAY be supported.
+
+4.4 ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
+
+ ICMPv6 [RFC-2463] MUST be supported.
+
+4.5 Addressing
+
+4.5.1 IP Version 6 Addressing Architecture - RFC3513
+
+ The IPv6 Addressing Architecture [RFC-3513] MUST be supported.
+
+4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462
+
+ IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
+ This specification MUST be supported for nodes that are hosts.
+
+ Nodes that are routers MUST be able to generate link local addresses
+ as described in RFC 2462 [RFC-2462].
+
+ From 2462:
+
+ The autoconfiguration process specified in this document applies
+ only to hosts and not routers. Since host autoconfiguration uses
+ information advertised by routers, routers will need to be
+ configured by some other means. However, it is expected that
+
+
+
+Loughney (editor) February 16, 2004 [Page 7]
+
+
+
+
+
+Internet-Draft
+
+
+ routers will generate link-local addresses using the mechanism
+ described in this document. In addition, routers are expected to
+ successfully pass the Duplicate Address Detection procedure
+ described in this document on all addresses prior to assigning
+ them to an interface.
+
+ Duplicate Address Detection (DAD) MUST be supported.
+
+4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041
+
+ Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
+ SHOULD be supported. It is recommended that this behavior be
+ configurable on a connection basis within each application when
+ available. It is noted that a number of applications do not work
+ with addresses generated with this method, while other applications
+ work quite well with them.
+
+4.5.4 Default Address Selection for IPv6 - RFC3484
+
+ The rules specified in the Default Address Selection for IPv6 [RFC-
+ 3484] document MUST be implemented. It is expected that IPv6 nodes
+ will need to deal with multiple addresses.
+
+4.5.5 Stateful Address Autoconfiguration
+
+ Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
+ 3315] is the standard stateful address configuration protocol; see
+ section 5.3 for DHCPv6 support.
+
+ Nodes which do not support Stateful Address Autoconfiguration may be
+ unable to obtain any IPv6 addresses aside from link-local addresses
+ when it receives a router advertisement with the 'M' flag (Managed
+ address configuration) set and which contains no prefixes advertised
+ for Stateless Address Autoconfiguration (see section 4.5.2).
+ Additionally, such nodes will be unable to obtain other configuration
+ information such as the addresses of DNS servers when it is connected
+ to a link over which the node receives a router advertisement in
+ which the 'O' flag ("Other stateful configuration") is set.
+
+4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
+
+ Nodes that need to join multicast groups SHOULD implement MLDv2
+ [MLDv2]. However, if the node has applications, which only need
+ support for Any- Source Multicast [RFC3569], the node MAY implement
+ MLDv1 [MLDv1] instead. If the node has applications, which need
+ support for Source- Specific Multicast [RFC3569, SSMARCH], the node
+ MUST support MLDv2 [MLDv2].
+
+
+
+
+Loughney (editor) February 16, 2004 [Page 8]
+
+
+
+
+
+Internet-Draft
+
+
+ When MLD is used, the rules in "Source Address Selection for the
+ Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
+ followed.
+
+5. Transport Layer and DNS
+
+5.1 Transport Layer
+
+5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147
+
+ This specification MUST be supported if jumbograms are implemented
+ [RFC- 2675].
+
+5.2 DNS
+
+ DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363]
+ and [RFC-3596] MAY be supported. Not all nodes will need to resolve
+ names. All nodes that need to resolve names SHOULD implement stub-
+ resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
+ support for:
+
+ - AAAA type Resource Records [RFC-3596];
+ - reverse addressing in ip6.arpa using PTR records [RFC-3152];
+ - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
+ octets.
+
+ Those nodes are RECOMMENDED to support DNS security extentions
+ [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT].
+
+ Those nodes are NOT RECOMMENDED to support the experimental A6 and
+ DNAME Resource Records [RFC-3363].
+
+5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732
+
+ RFC 2732 MUST be supported if applications on the node use URL's.
+
+5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315
+
+5.3.1 Managed Address Configuration
+
+ Those IPv6 Nodes that use DHCP for address assignment initiate DHCP
+ to obtain IPv6 addresses and other configuration information upon
+ receipt of a Router Advertisement with the 'M' flag set, as described
+ in section 5.5.3 of RFC 2462. In addition, in the absence of a
+ router, those IPv6 Nodes that use DHCP for address assignment MUST
+ initiate DHCP to obtain IPv6 addresses and other configuration
+ information, as described in section 5.5.2 of RFC 2462. Those IPv6
+ nodes that do not use DHCP for address assignment can ignore the 'M'
+
+
+
+Loughney (editor) February 16, 2004 [Page 9]
+
+
+
+
+
+Internet-Draft
+
+
+ flag in Router Advertisements.
+
+5.3.2 Other Configuration Information
+
+ Those IPv6 Nodes that use DHCP to obtain other configuration
+ information initiate DHCP for other configuration information upon
+ receipt of a Router Advertisement with the 'O' flag set, as described
+ in section 5.5.3 of RFC 2462. Those IPv6 nodes that do not use DHCP
+ for other configuration information can ignore the 'O' flag in Router
+ Advertisements.
+
+ An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to
+ obtain other configuration information.
+
+6. IPv4 Support and Transition
+
+ IPv6 nodes MAY support IPv4.
+
+6.1 Transition Mechanisms
+
+6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893
+
+ If an IPv6 node implements dual stack and tunneling, then RFC2893
+ MUST be supported.
+
+ RFC 2893 is currently being updated.
+
+7. Mobile IP
+
+ The Mobile IPv6 [MIPv6] specification defines requirements for the
+ following types of nodes:
+
+ - mobile nodes
+ - correspondent nodes with support for route optimization
+ - home agents
+ - all IPv6 routers
+
+ Hosts MAY support mobile node functionality described in Section 8.5
+ of [MIPv6], including support of generic packet tunneling [RFC-2473]
+ and secure home agent communications [MIPv6-HASEC].
+
+ Hosts SHOULD support route optimization requirements for
+ correspondent nodes described in Section 8.2 of [MIPv6].
+
+ Routers SHOULD support the generic mobility-related requirements for
+ all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY
+ support the home agent functionality described in Section 8.4 of
+ [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC].
+
+
+
+Loughney (editor) February 16, 2004 [Page 10]
+
+
+
+
+
+Internet-Draft
+
+
+8. Security
+
+ This section describes the specification of IPsec for the IPv6 node.
+
+8.1 Basic Architecture
+
+ Security Architecture for the Internet Protocol [RFC-2401] MUST be
+ supported. RFC-2401 is being updated by the IPsec Working Group.
+
+8.2 Security Protocols
+
+ ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported.
+ RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group.
+
+
+8.3 Transforms and Algorithms
+
+ Current IPsec RFCs specify the support of certain transforms and
+ algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96.
+ The requirements for these are discussed first, and then additional
+ algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed.
+
+ NULL encryption algorithm [RFC-2410] MUST be supported for providing
+ integrity service and also for debugging use.
+
+ The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD
+ NOT be supported. Security issues related to the use of DES are
+ discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as
+ required by the existing IPsec RFCs, but as it is currently viewed as
+ an inherently weak algorithm, and no longer fulfills its intended
+ role.
+
+ The NULL authentication algorithm [RFC-2406] MUST be supported within
+ ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC-
+ 2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP,
+ described in [RFC-2403] MUST be supported. An implementer MUST refer
+ to Keyed- Hashing for Message Authentication [RFC-2104].
+
+ 3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
+ and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES-
+ CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected
+ to be a widely available, secure algorithm that is required for
+ interoperability. It is not required by the current IPsec RFCs, but
+ is expected to become required in the future.
+
+ In addition to the above requirements, "Cryptographic Algorithm
+ Implementation Requirements For ESP And AH" [CRYPTREQ] contains the
+ current set of mandatory to implement algorithms for ESP and AH as
+
+
+
+Loughney (editor) February 16, 2004 [Page 11]
+
+
+
+
+
+Internet-Draft
+
+
+ well as specifying algorithms that should be implemented because they
+ may be promoted to mandatory at some future time. It is RECOMMENDED
+ that IPv6 nodes conform to the requirements in this document.
+
+8.4 Key Management Methods
+
+ Manual keying MUST be supported.
+
+ IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast
+ traffic. Where key refresh, anti-replay features of AH and ESP, or
+ on- demand creation of Security Associations (SAs) is required,
+ automated keying MUST be supported. Note that the IPsec WG is working
+ on the successor to IKE [IKE2]. Key management methods for multicast
+ traffic are also being worked on by the MSEC WG.
+
+ "Cryptographic Algorithms for use in the Internet Key Exchange
+ Version 2" [IKEv2ALGO] defines the current set of mandatory to
+ implement algorithms for use of IKEv2 as well as specifying
+ algorithms that should be implemented because they made be promoted
+ to mandatory at some future time. It is RECOMMENDED that IPv6 nodes
+ implementing IKEv2 conform to the requirements in this
+ document.
+
+9. Router-Specific Functionality
+
+ This section defines general host considerations for IPv6 nodes that
+ act as routers. Currently, this section does not discuss routing-
+ specific requirements.
+
+9.1 General
+
+9.1.1 IPv6 Router Alert Option - RFC2711
+
+
+ The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
+ Hop Header that is used in conjunction with some protocols (e.g.,
+ RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will
+ need to be implemented whenever protocols that mandate its usage are
+ implemented. See Section 4.6.
+
+9.1.2 Neighbor Discovery for IPv6 - RFC2461
+
+ Sending Router Advertisements and processing Router Solicitation MUST
+ be supported.
+
+10. Network Management
+
+ Network Management MAY be supported by IPv6 nodes. However, for IPv6
+
+
+
+Loughney (editor) February 16, 2004 [Page 12]
+
+
+
+
+
+Internet-Draft
+
+
+ nodes that are embedded devices, network management may be the only
+ possibility to control these nodes.
+
+10.1 Management Information Base Modules (MIBs)
+
+ The following two MIBs SHOULD be supported by nodes that support an
+ SNMP agent.
+
+10.1.1 IP Forwarding Table MIB
+
+ IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes
+ that support an SNMP agent.
+
+10.1.2 Management Information Base for the Internet Protocol (IP)
+
+ IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an
+ SNMP agent.
+
+11. Security Considerations
+
+ This draft does not affect the security of the Internet, but
+ implementations of IPv6 are expected to support a minimum set of
+ security features to ensure security on the Internet. "IP Security
+ Document Roadmap" [RFC-2411] is important for everyone to read.
+
+ The security considerations in RFC2460 describe the following:
+
+ The security features of IPv6 are described in the Security
+ Architecture for the Internet Protocol [RFC-2401].
+
+12. References
+
+12.1 Normative
+
+ [CRYPTREQ] D. Eastlake 3rd, "Cryptographic Algorithm Implementa-
+ tion Requirements For ESP And AH", draft-ietf-ipsec-
+ esp-ah-algorithms-01.txt, January 2004.
+
+ [IKEv2ALGO] J. Schiller, "Cryptographic Algorithms for use in the
+ Internet Key Exchange Version 2", draft-ietf-ipsec-
+ ikev2-algorithms-04.txt, Work in Progress.
+
+ [DHCPv6-SL] R. Droms, "A Guide to Implementing Stateless DHCPv6
+ Service", draft- ietf-dhc-dhcpv6-stateless-00.txt,
+ Work in Progress.
+
+ [MIPv6] J. Arkko, D. Johnson and C. Perkins, "Mobility Support
+ in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in
+
+
+
+Loughney (editor) February 16, 2004 [Page 13]
+
+
+
+
+
+Internet-Draft
+
+
+ progress.
+
+ [MIPv6-HASEC] J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec
+ to Protect Mobile IPv6 Signaling between Mobile Nodes
+ and Home Agents", draft-ietf- mobileip-mipv6-ha-
+ ipsec-06.txt, Work in Progress.
+
+ [MLDv2] Vida, R. et al., "Multicast Listener Discovery Version
+ 2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in
+ Progress.
+
+ [RFC-1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC-1981] McCann, J., Mogul, J. and Deering, S., "Path MTU
+ Discovery for IP version 6", RFC 1981, August 1996.
+
+ [RFC-2096BIS] Haberman, B. and Wasserman, M., "IP Forwarding Table
+ MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in
+ Progress.
+
+ [RFC-2011BIS] Routhier, S (ed), "Management Information Base for the
+ Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-
+ update-07.txt, Work in progress.
+
+ [RFC-2104] Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:
+ Keyed-Hashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC-2401] Kent, S. and Atkinson, R., "Security Architecture for
+ the Internet Protocol", RFC 2401, November 1998.
+
+ [RFC-2402] Kent, S. and Atkinson, R., "IP Authentication
+ Header", RFC 2402, November 1998.
+
+ [RFC-2403] Madson, C., and Glenn, R., "The Use of HMAC-MD5 within
+ ESP and AH", RFC 2403, November 1998.
+
+ [RFC-2404] Madson, C., and Glenn, R., "The Use of HMAC-SHA-1
+ within ESP and AH", RFC 2404, November 1998.
+
+ [RFC-2405] Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
+ Algorithm With Explicit IV", RFC 2405, November 1998.
+
+ [RFC-2406] Kent, S. and Atkinson, R., "IP Encapsulating Security
+
+
+
+Loughney (editor) February 16, 2004 [Page 14]
+
+
+
+
+
+Internet-Draft
+
+
+ Protocol (ESP)", RFC 2406, November 1998.
+
+ [RFC-2407] Piper, D., "The Internet IP Security Domain of
+ Interpretation for ISAKMP", RFC 2407, November 1998.
+
+ [RFC-2408] Maughan, D., Schertler, M., Schneider, M., and Turner,
+ J., "Internet Security Association and Key Management
+ Protocol (ISAKMP)", RFC 2408, November 1998.
+
+ [RFC-2409] Harkins, D., and Carrel, D., "The Internet Key
+ Exchange (IKE)", RFC 2409, November 1998.
+
+ [RFC-2410] Glenn, R. and Kent, S., "The NULL Encryption Algorithm
+ and Its Use With IPsec", RFC 2410, November 1998.
+
+ [RFC-2451] Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher
+ Algorithms", RFC 2451, November 1998.
+
+ [RFC-2460] Deering, S. and Hinden, R., "Internet Protocol, Ver-
+ sion 6 (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC-2461] Narten, T., Nordmark, E. and Simpson, W., "Neighbor
+ Discovery for IP Version 6 (IPv6)", RFC 2461, December
+ 1998.
+
+ [RFC-2462] Thomson, S. and Narten, T., "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462.
+
+ [RFC-2463] Conta, A. and Deering, S., "ICMP for the Internet Pro-
+ tocol Version 6 (IPv6)", RFC 2463, December 1998.
+
+ [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
+ 2472, December 1998.
+
+ [RFC-2473] Conta, A. and Deering, S., "Generic Packet Tunneling
+ in IPv6 Specification", RFC 2473, December 1998. Xxx
+ add
+
+ [RFC-2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC-2710] Deering, S., Fenner, W. and Haberman, B., "Multicast
+ Listener Discovery (MLD) for IPv6", RFC 2710, October
+ 1999.
+
+ [RFC-2711] Partridge, C. and Jackson, A., "IPv6 Router Alert
+ Option", RFC 2711, October 1999.
+
+
+
+
+Loughney (editor) February 16, 2004 [Page 15]
+
+
+
+
+
+Internet-Draft
+
+
+ [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for
+ Stateless Address Autoconfiguration in IPv6", RFC
+ 3041, January 2001.
+
+ [RFC-3152] Bush, R., "Delegation of IP6.ARPA", RFC 3152, August
+ 2001.
+
+ [RFC-3315] Bound, J. et al., "Dynamic Host Configuration Protocol
+ for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+ [RFC-3363] Bush, R., et al., "Representing Internet Protocol ver-
+ sion 6 (IPv6) Addresses in the Domain Name System
+ (DNS)", RFC 3363, August 2002.
+
+ [RFC-3484] Draves, R., "Default Address Selection for IPv6", RFC
+ 3484, February 2003.
+
+ [RFC-3513] Hinden, R. and Deering, S. "IP Version 6 Addressing
+ Architecture", RFC 3513, April 2003.
+
+ [RFC-3590] Haberman, B., "Source Address Selection for the Multi-
+ cast Listener Discovery (MLD) Protocol", RFC 3590,
+ September 2003.
+
+ [RFC-3596] Thomson, S., et al., "DNS Extensions to support IP
+ version 6", RFC 3596, October 2003.
+
+ [RFC-3602] S. Frankel, "The AES-CBC Cipher Algorithm and Its Use
+ with IPsec", RFC 3602, September 2003.
+
+12.2 Non-Normative
+
+ [ANYCAST] Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast",
+ draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in
+ Progress.
+
+ [DESDIFF] Biham, E., Shamir, A., "Differential Cryptanalysis of
+ DES-like cryptosystems", Journal of Cryptology Vol 4, Jan
+ 1991.
+
+ [DESCRACK] Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
+
+ [DESINT] Bellovin, S., "An Issue With DES-CBC When Used Without
+ Strong Integrity", Proceedings of the 32nd IETF, Danvers,
+ MA, April 1995.
+
+ [DHCPv6-SL] Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser-
+ vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in
+
+
+
+Loughney (editor) February 16, 2004 [Page 16]
+
+
+
+
+
+Internet-Draft
+
+
+ Progress.
+
+ [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
+ S., "DNS Security Introduction and Requirements" draft-
+ ietf-dnsext-dnssec-intro- 06.txt, Work in Progress.
+
+ [DNSSEC-REC] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
+ S., "Resource Records for the DNS Security Extensions",
+ draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro-
+ gress.
+
+ [DNSSEC-PROT] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
+ S., "Protocol Modifications for the DNS Security Exten-
+ sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work
+ in Progress.
+
+ [IKE2] Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto-
+ col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress.
+
+ [IPv6-RH] P. Savola, "Security of IPv6 Routing Header and Home
+ Address Options", draft-savola-ipv6-rh-ha-security-
+ 03.txt, Work in Progress, March 2002.
+
+ [MC-THREAT] Ballardie A. and Crowcroft, J.; Multicast-Specific Secu-
+ rity Threats and Counter-Measures; In Proceedings "Sympo-
+ sium on Network and Distributed System Security", Febru-
+ ary 1995, pp.2-16.
+
+ [RFC-793] Postel, J., "Transmission Control Protocol", RFC 793,
+ August 1980.
+
+ [RFC-1034] Mockapetris, P., "Domain names - concepts and facili-
+ ties", RFC 1034, November 1987.
+
+ [RFC-2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147,
+ May 1997.
+
+ [RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and
+ S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC
+ 2205, September 1997.
+
+ [RFC-2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
+ Networks", RFC 2462, December 1998.
+
+ [RFC-2492] G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over
+ ATM Networks", RFC 2492, January 1999.
+
+ [RFC-2675] Borman, D., Deering, S. and Hinden, B., "IPv6
+
+
+
+Loughney (editor) February 16, 2004 [Page 17]
+
+
+
+
+
+Internet-Draft
+
+
+ Jumbograms", RFC 2675, August 1999.
+
+ [RFC-2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
+ IPv6 Addresses in URL's", RFC 2732, December 1999.
+
+ [RFC-2851] M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
+ "Textual Conventions for Internet Network Addresses", RFC
+ 2851, June 2000.
+
+ [RFC-2893] Gilligan, R. and Nordmark, E., "Transition Mechanisms for
+ IPv6 Hosts and Routers", RFC 2893, August 2000.
+
+ [RFC-3569] S. Bhattacharyya, Ed., "An Overview of Source-Specific
+ Multicast (SSM)", RFC 3569, July 2003.
+
+ [SSM-ARCH] H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
+ draft-ietf- ssm-arch-03.txt, Work in Progress.
+
+13. Authors and Acknowledgements
+
+ This document was written by the IPv6 Node Requirements design team:
+
+ Jari Arkko
+ [jari.arkko@ericsson.com]
+
+ Marc Blanchet
+ [marc.blanchet@viagenie.qc.ca]
+
+ Samita Chakrabarti
+ [samita.chakrabarti@eng.sun.com]
+
+ Alain Durand
+ [alain.durand@sun.com]
+
+ Gerard Gastaud
+ [gerard.gastaud@alcatel.fr]
+
+ Jun-ichiro itojun Hagino
+ [itojun@iijlab.net]
+
+ Atsushi Inoue
+ [inoue@isl.rdc.toshiba.co.jp]
+
+ Masahiro Ishiyama
+ [masahiro@isl.rdc.toshiba.co.jp]
+
+ John Loughney
+ [john.loughney@nokia.com]
+
+
+
+Loughney (editor) February 16, 2004 [Page 18]
+
+
+
+
+
+Internet-Draft
+
+
+ Rajiv Raghunarayan
+ [raraghun@cisco.com]
+
+ Shoichi Sakane
+ [shouichi.sakane@jp.yokogawa.com]
+
+ Dave Thaler
+ [dthaler@windows.microsoft.com]
+
+ Juha Wiljakka
+ [juha.wiljakka@Nokia.com]
+
+ The authors would like to thank Ran Atkinson, Jim Bound, Brian Car-
+ penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten,
+ Juha Ollila and Pekka Savola for their comments.
+
+14. Editor's Contact Information
+
+ Comments or questions regarding this document should be sent to the
+ IPv6 Working Group mailing list (ipv6@ietf.org) or to:
+
+ John Loughney
+ Nokia Research Center
+ Itamerenkatu 11-13
+ 00180 Helsinki
+ Finland
+
+ Phone: +358 50 483 6242
+ Email: John.Loughney@Nokia.com
+
+Notices
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to per-
+ tain 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; neither does it represent that it has made
+ any effort to identify any such rights. Information on the IETF's
+ procedures with respect to rights in standards-track and standards-
+ related documentation can be found in BCP-11. Copies of claims of
+ rights made available for publication 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 implementors or users of this specification can be obtained from
+ the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+
+
+
+Loughney (editor) February 16, 2004 [Page 19]
+
+
+
+
+
+Internet-Draft
+
+
+ rights, which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Loughney (editor) February 16, 2004 [Page 20]
+
+
diff --git a/doc/draft/draft-ietf-secsh-dns-05.txt b/doc/draft/draft-ietf-secsh-dns-05.txt
new file mode 100644
index 0000000..a272d81
--- /dev/null
+++ b/doc/draft/draft-ietf-secsh-dns-05.txt
@@ -0,0 +1,614 @@
+Secure Shell Working Group J. Schlyter
+Internet-Draft OpenSSH
+Expires: March 5, 2004 W. Griffin
+ SPARTA
+ September 5, 2003
+
+
+ Using DNS to Securely Publish SSH Key Fingerprints
+ draft-ietf-secsh-dns-05.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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 March 5, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ This document describes a method to verify SSH host keys using
+ DNSSEC. The document defines a new DNS resource record that contains
+ a standard SSH key fingerprint.
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 1]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3
+ 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3
+ 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4
+ 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4
+ 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 5
+ 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5
+ 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5
+ 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . 6
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
+ Normative References . . . . . . . . . . . . . . . . . . . . 8
+ Informational References . . . . . . . . . . . . . . . . . . 8
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
+ A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
+ Intellectual Property and Copyright Statements . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 2]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+1. Introduction
+
+ The SSH [6] protocol provides secure remote login and other secure
+ network services over an insecure network. The security of the
+ connection relies on the server authenticating itself to the client
+ as well as the user authenticating itself to the server.
+
+ If a connection is established to a server whose public key is not
+ already known to the client, a fingerprint of the key is presented to
+ the user for verification. If the user decides that the fingerprint
+ is correct and accepts the key, the key is saved locally and used for
+ verification for all following connections. While some
+ security-conscious users verify the fingerprint out-of-band before
+ accepting the key, many users blindly accept the presented key.
+
+ The method described here can provide out-of-band verification by
+ looking up a fingerprint of the server public key in the DNS [1][2]
+ and using DNSSEC [5] to verify the lookup.
+
+ In order to distribute the fingerprint using DNS, this document
+ defines a new DNS resource record, "SSHFP", to carry the fingerprint.
+
+ Basic understanding of the DNS system [1][2] and the DNS security
+ extensions [5] is assumed by 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 RFC 2119 [3].
+
+2. SSH Host Key Verification
+
+2.1 Method
+
+ Upon connection to a SSH server, the SSH client MAY look up the SSHFP
+ resource record(s) for the host it is connecting to. If the
+ algorithm and fingerprint of the key received from the SSH server
+ match the algorithm and fingerprint of one of the SSHFP resource
+ record(s) returned from DNS, the client MAY accept the identity of
+ the server.
+
+2.2 Implementation Notes
+
+ Client implementors SHOULD provide a configurable policy used to
+ select the order of methods used to verify a host key. This document
+ defines one method: Fingerprint storage in DNS. Another method
+ defined in the SSH Architecture [6] uses local files to store keys
+ for comparison. Other methods that could be defined in the future
+ might include storing fingerprints in LDAP or other databases. A
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 3]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+ configurable policy will allow administrators to determine which
+ methods they want to use and in what order the methods should be
+ prioritized. This will allow administrators to determine how much
+ trust they want to place in the different methods.
+
+ One specific scenario for having a configurable policy is where
+ clients do not use fully qualified host names to connect to servers.
+ In this scenario, the implementation SHOULD verify the host key
+ against a local database before verifying the key via the fingerprint
+ returned from DNS. This would help prevent an attacker from injecting
+ a DNS search path into the local resolver and forcing the client to
+ connect to a different host.
+
+2.3 Fingerprint Matching
+
+ The public key and the SSHFP resource record are matched together by
+ comparing algorithm number and fingerprint.
+
+ The public key algorithm and the SSHFP algorithm number MUST
+ match.
+
+ A message digest of the public key, using the message digest
+ algorithm specified in the SSHFP fingerprint type, MUST match the
+ SSHFP fingerprint.
+
+
+2.4 Authentication
+
+ A public key verified using this method MUST NOT be trusted if the
+ SSHFP resource record (RR) used for verification was not
+ authenticated by a trusted SIG RR.
+
+ Clients that do validate the DNSSEC signatures themselves SHOULD use
+ standard DNSSEC validation procedures.
+
+ Clients that do not validate the DNSSEC signatures themselves MUST
+ use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
+ between themselves and the entity performing the signature
+ validation.
+
+3. The SSHFP Resource Record
+
+ The SSHFP resource record (RR) is used to store a fingerprint of a
+ SSH public host key that is associated with a Domain Name System
+ (DNS) name.
+
+ The RR type code for the SSHFP RR is TBA.
+
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 4]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+3.1 The SSHFP RDATA Format
+
+ The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
+ type and the fingerprint of the public host key.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | algorithm | fp type | /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
+ / /
+ / fingerprint /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+3.1.1 Algorithm Number Specification
+
+ This algorithm number octet describes the algorithm of the public
+ key. The following values are assigned:
+
+ Value Algorithm name
+ ----- --------------
+ 0 reserved
+ 1 RSA
+ 2 DSS
+
+ Reserving other types requires IETF consensus [4].
+
+3.1.2 Fingerprint Type Specification
+
+ The fingerprint type octet describes the message-digest algorithm
+ used to calculate the fingerprint of the public key. The following
+ values are assigned:
+
+ Value Fingerprint type
+ ----- ----------------
+ 0 reserved
+ 1 SHA-1
+
+ Reserving other types requires IETF consensus [4].
+
+ For interoperability reasons, as few fingerprint types as possible
+ should be reserved. The only reason to reserve additional types is
+ to increase security.
+
+3.1.3 Fingerprint
+
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 5]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+ The fingerprint is calculated over the public key blob as described
+ in [7].
+
+ The message-digest algorithm is presumed to produce an opaque octet
+ string output which is placed as-is in the RDATA fingerprint field.
+
+3.2 Presentation Format of the SSHFP RR
+
+ The RDATA of the presentation format of the SSHFP resource record
+ consists of two numbers (algorithm and fingerprint type) followed by
+ the fingerprint itself presented in hex, e.g:
+
+ host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
+
+ The use of mnemonics instead of numbers is not allowed.
+
+4. Security Considerations
+
+ Currently, the amount of trust a user can realistically place in a
+ server key is proportional to the amount of attention paid to
+ verifying that the public key presented actually corresponds to the
+ private key of the server. If a user accepts a key without verifying
+ the fingerprint with something learned through a secured channel, the
+ connection is vulnerable to a man-in-the-middle attack.
+
+ The overall security of using SSHFP for SSH host key verification is
+ dependent on the security policies of the SSH host administrator and
+ DNS zone administrator (in transferring the fingerprint), detailed
+ aspects of how verification is done in the SSH implementation, and in
+ the client's diligence in accessing the DNS in a secure manner.
+
+ One such aspect is in which order fingerprints are looked up (e.g.
+ first checking local file and then SSHFP). We note that in addition
+ to protecting the first-time transfer of host keys, SSHFP can
+ optionally be used for stronger host key protection.
+
+ If SSHFP is checked first, new SSH host keys may be distributed by
+ replacing the corresponding SSHFP in DNS.
+
+ If SSH host key verification can be configured to require SSHFP,
+ SSH host key revocation can be implemented by removing the
+ corresponding SSHFP from DNS.
+
+ As stated in Section 2.2, we recommend that SSH implementors provide
+ a policy mechanism to control the order of methods used for host key
+ verification. One specific scenario for having a configurable policy
+ is where clients use unqualified host names to connect to servers. In
+ this case, we recommend that SSH implementations check the host key
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 6]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+ against a local database before verifying the key via the fingerprint
+ returned from DNS. This would help prevent an attacker from injecting
+ a DNS search path into the local resolver and forcing the client to
+ connect to a different host.
+
+ A different approach to solve the DNS search path issue would be for
+ clients to use a trusted DNS search path, i.e., one not acquired
+ through DHCP or other autoconfiguration mechanisms. Since there is no
+ way with current DNS lookup APIs to tell whether a search path is
+ from a trusted source, the entire client system would need to be
+ configured with this trusted DNS search path.
+
+ Another dependency is on the implementation of DNSSEC itself. As
+ stated in Section 2.4, we mandate the use of secure methods for
+ lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This
+ is especially important if SSHFP is to be used as a basis for host
+ key rollover and/or revocation, as described above.
+
+ Since DNSSEC only protects the integrity of the host key fingerprint
+ after it is signed by the DNS zone administrator, the fingerprint
+ must be transferred securely from the SSH host administrator to the
+ DNS zone administrator. This could be done manually between the
+ administrators or automatically using secure DNS dynamic update [11]
+ between the SSH server and the nameserver. We note that this is no
+ different from other key enrollment situations, e.g. a client sending
+ a certificate request to a certificate authority for signing.
+
+5. IANA Considerations
+
+ IANA needs to allocate a RR type code for SSHFP from the standard RR
+ type space (type 44 requested).
+
+ IANA needs to open a new registry for the SSHFP RR type for public
+ key algorithms. Defined types are:
+
+ 0 is reserved
+ 1 is RSA
+ 2 is DSA
+
+ Adding new reservations requires IETF consensus [4].
+
+ IANA needs to open a new registry for the SSHFP RR type for
+ fingerprint types. Defined types are:
+
+ 0 is reserved
+ 1 is SHA-1
+
+ Adding new reservations requires IETF consensus [4].
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 7]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+Normative References
+
+ [1] Mockapetris, P., "Domain names - concepts and facilities", STD
+ 13, RFC 1034, November 1987.
+
+ [2] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+ [5] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
+ Lehtinen, "SSH Protocol Architecture",
+ draft-ietf-secsh-architecture-14 (work in progress), July 2003.
+
+ [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
+ Lehtinen, "SSH Transport Layer Protocol",
+ draft-ietf-secsh-transport-16 (work in progress), July 2003.
+
+Informational References
+
+ [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
+ Roadmap", RFC 2411, November 1998.
+
+ [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+ "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+ 2845, May 2000.
+
+ [10] Eastlake, D., "DNS Request and Transaction Signatures (
+ SIG(0)s)", RFC 2931, September 2000.
+
+ [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 8]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+Authors' Addresses
+
+ Jakob Schlyter
+ OpenSSH
+ 812 23rd Avenue SE
+ Calgary, Alberta T2G 1N8
+ Canada
+
+ EMail: jakob@openssh.com
+ URI: http://www.openssh.com/
+
+
+ Wesley Griffin
+ SPARTA
+ 7075 Samuel Morse Drive
+ Columbia, MD 21046
+ USA
+
+ EMail: wgriffin@sparta.com
+ URI: http://www.sparta.com/
+
+Appendix A. Acknowledgements
+
+ The authors gratefully acknowledge, in no particular order, the
+ contributions of the following persons:
+
+ Martin Fredriksson
+
+ Olafur Gudmundsson
+
+ Edward Lewis
+
+ Bill Sommerfeld
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 9]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property 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; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 10]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
+
+
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Schlyter & Griffin Expires March 5, 2004 [Page 11]
+
diff --git a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
new file mode 100644
index 0000000..3578d2a
--- /dev/null
+++ b/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
@@ -0,0 +1,519 @@
+
+Internet Draft Johan Ihren
+draft-ihren-dnsext-threshold-validation-00.txt Autonomica
+February 2003
+Expires in six months
+
+
+ Threshold Validation:
+
+ A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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.
+
+
+Abstract
+
+ This memo documents a proposal for a different method of validation
+ for DNSSEC aware resolvers. The key change is that by changing from
+ a model of one Key Signing Key, KSK, at a time to multiple KSKs it
+ will be possible to increase the aggregated trust in the signed
+ keys by leveraging from the trust associated with the different
+ signees.
+
+ By having multiple keys to chose from validating resolvers get the
+ opportunity to use local policy to reflect actual trust in
+ different keys. For instance, it is possible to trust a single,
+ particular key ultimately, while requiring multiple valid
+ signatures by less trusted keys for validation to succeed.
+ Furthermore, with multiple KSKs there are additional redundancy
+ benefits available since it is possible to roll over different KSKs
+ at different times which may make rollover scenarios easier to
+ manage.
+
+Contents
+
+ 1. Terminology
+ 2. Introduction and Background
+
+ 3. Trust in DNSSEC Keys
+ 3.1. Key Management, Split Keys and Trust Models
+ 3.2. Trust Expansion: Authentication versus Authorization
+
+ 4. Proposed Semantics for Signing the KEY Resource Record
+ Set
+ 4.1. Packet Size Considerations
+
+ 5. Proposed Use of Multiple "Trusted Keys" in a Validating
+ Resolver
+ 5.1. Not All Possible KSKs Need to Be Trusted
+ 5.2. Possible to do Threshold Validation
+ 5.3. Not All Trusted Keys Will Be Available
+
+ 6. Additional Benefits from Having Multiple KSKs
+ 6.1. More Robust Key Rollovers
+ 6.2. Evaluation of Multiple Key Distribution Mechanisms
+
+ 7. Security Considerations
+ 8. IANA Considerations.
+ 9. References
+ 9.1. Normative.
+ 9.2. Informative.
+ 10. Acknowledgments.
+ 11. Authors' Address
+
+
+1. Terminology
+
+ The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+ and "MAY" in this document are to be interpreted as described in
+ RFC 2119.
+
+ The term "zone" refers to the unit of administrative control in the
+ Domain Name System. "Name server" denotes a DNS name server that is
+ authoritative (i.e. knows all there is to know) for a DNS zone,
+ typically the root zone. A "resolver", is a DNS "client", i.e. an
+ entity that sends DNS queries to authoritative nameservers and
+ interpret the results. A "validating resolver" is a resolver that
+ attempts to perform DNSSEC validation on data it retrieves by doing
+ DNS lookups.
+
+
+2. Introduction and Background
+
+ From a protocol perspective there is no real difference between
+ different keys in DNSSEC. They are all just keys. However, in
+ actual use there is lots of difference. First and foremost, most
+ DNSSEC keys have in-band verification. I.e. the keys are signed by
+ some other key, and this other key is in its turn also signed by
+ yet another key. This way a "chain of trust" is created. Such
+ chains have to end in what is referred to as a "trusted key" for
+ validation of DNS lookups to be possible.
+
+ A "trusted key" is a the public part of a key that the resolver
+ acquired by some other means than by looking it up in DNS. The
+ trusted key has to be explicitly configured.
+
+ A node in the DNS hierarchy that issues such out-of-band "trusted
+ keys" is called a "security apex" and the trusted key for that apex
+ is the ultimate source of trust for all DNS lookups within that
+ entire subtree.
+
+ DNSSEC is designed to be able to work with more than on security
+ apex. These apexes will all share the problem of how to distribute
+ their "trusted keys" in a way that provides validating resolvers
+ confidence in the distributed keys.
+
+ Maximizing that confidence is crucial to the usefulness of DNSSEC
+ and this document tries to address this issue.
+
+
+3. Trust in DNSSEC Keys
+
+ In the end the trust that a validating resolver will be able to put
+ in a key that it cannot validate within DNSSEC will have to be a
+ function of
+
+ * trust in the key issuer, aka the KSK holder
+
+ * trust in the distribution method
+
+ * trust in extra, out-of-band verification
+
+ The KSK holder needs to be trusted not to accidentally lose private
+ keys in public places. Furthermore it needs to be trusted to
+ perform correct identification of the ZSK holders in case they are
+ separate from the KSK holder itself.
+
+ The distribution mechanism can be more or less tamper-proof. If the
+ key holder publishes the public key, or perhaps just a secure
+ fingerprint of the key in a major newspaper it may be rather
+ difficult to tamper with. A key acquired that way may be easier to
+ trust than if it had just been downloaded from a web page.
+
+ Out-of-band verification can for instance be the key being signed
+ by a certificate issued by a known Certificate Authority that the
+ resolver has reason to trust.
+
+3.1. Simplicity vs Trust
+
+ The fewer keys that are in use the simpler the key management
+ becomes. Therefore increasing the number of keys should only be
+ considered when the complexity is not the major concern. A perfect
+ example of this is the distinction between so called Key Signing
+ Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
+ overall complexity but simplifies real life operations and was an
+ overall gain since operational simplification was considered to be
+ a more crucial issue than the added complexity.
+
+ In the case of a security apex there are additional issues to
+ consider, among them
+
+ * maximizing trust in the KSK received out-of-band
+
+ * authenticating the legitimacy of the ZSKs used
+
+ In some cases this will be easy, since the same entity will manage
+ both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
+ similar to a self-signed certificate). In some environments it will
+ be possible to get the trusted key installed in the resolver end by
+ decree (this would seem to be a likely method within corporate and
+ government environments).
+
+ In other cases, however, this will possibly not be sufficient. In
+ the case of the root zone this is obvious, but there may well be
+ other cases.
+
+3.2. Expanding the "Trust Base"
+
+ For a security apex where the ZSKs and KSK are not held by the same
+ entity the KSK will effectively authenticate the identity of
+ whoever does real operational zone signing. The amount of trust
+ that the data signed by a ZSK will get is directly dependent on
+ whether the end resolver trusts the KSK or not, since the resolver
+ has no OOB access to the public part of the ZSKs (for practical
+ reasons).
+
+ Since the KSK holder is distinct from the ZSK holder the obvious
+ question is whether it would then be possible to further improve
+ the situation by using multiple KSK holders and thereby expanding
+ the trust base to the union of that available to each individual
+ KSK holder. "Trust base" is an invented term intended to signify
+ the aggregate of Internet resolvers that will eventually choose to
+ trust a key issued by a particular KSK holder.
+
+ A crucial issue when considering trust expansion through addition
+ of multiple KSK holders is that the KSK holders are only used to
+ authenticate the ZSKs used for signing the zone. I.e. the function
+ performed by the KSK is basically:
+
+ "This is indeed the official ZSK holder for this zone,
+ I've verified this fact to the best of my abilitites."
+
+ Which can be thought of as similar to the service of a public
+ notary. I.e. the point with adding more KSK holders is to improve
+ the public trust in data signed by the ZSK holders by improving the
+ strength of available authentication.
+
+ Therefore adding more KSK holders, each with their own trust base,
+ is by definition a good thing. More authentication is not
+ controversial. On the contrary, when it comes to authentication,
+ the more the merrier.
+
+
+4. Proposed Semantics for Signing the KEY Resource Record Set
+
+ In DNSSEC according to RFC2535 all KEY Resource Records are used to
+ sign all authoritative data in the zone, including the KEY RRset
+ itself, since RFC2535 makes no distinction between Key Signing
+ Keys, KSK, and Zone Signing Keys, ZSK. With Delegation Signer [DS]
+ it is possible to change this to the KEY RRset being signed with
+ all KSKs and ZSKs but the rest of the zone only being signed by the
+ ZSKs.
+
+ This proposal changes this one step further, by recommending that
+ the KEY RRset is only signed by the Key Signing Keys, KSK, and
+ explicitly not by the Zone Signing Keys, ZSK. The reason for this
+ is to maximize the amount of space in the DNS response packet that
+ is available for additional KSKs and signatures thereof. The rest
+ of the authoritative zone contents are as previously signed by only
+ the ZSKs.
+
+4.1. Packet Size Considerations
+
+ The reason for the change is to keep down the size of the aggregate
+ of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
+ perform validation of data below a security apex. For DNSSEC data
+ to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
+ set, and therefore the allowed packet size can be assumed to be at
+ least the EDNS0 minimum of 4000 bytes.
+
+ When querying for KEY + SIG(KEY) for "." (the case that is assumed
+ to be most crucial) the size of the response packet after the
+ change to only sign the KEY RR with the KSKs break down into a
+ rather large space of possibilities. Here are a few examples for
+ the possible alternatives for different numbers of KSKs and ZSKs
+ for some different key lengths (all RSA keys, with a public
+ exponent that is < 254). This is all based upon the size of the
+ response for the particular example of querying for
+
+ ". KEY IN"
+
+ with a response of entire KEY + SIG(KEY) with the authority and
+ additional sections empty:
+
+ ZSK/768 and KSK/1024 (real small)
+ Max 12 KSK + 3 ZSK at 3975
+ 10 KSK + 8 ZSK at 3934
+ 8 KSK + 13 ZSK at 3893
+
+ ZSK/768 + KSK/1280
+ MAX 10 KSK + 2 ZSK at 3913
+ 8 KSK + 9 ZSK at 3970
+ 6 KSK + 15 ZSK at 3914
+
+ ZSK/768 + KSK/1536
+ MAX 8 KSK + 4 ZSK at 3917
+ 7 KSK + 8 ZSK at 3938
+ 6 KSK + 12 ZSK at 3959
+
+ ZSK/768 + KSK/2048
+ MAX 6 KSK + 5 ZSK at 3936
+ 5 KSK + 10 ZSK at 3942
+
+ ZSK/1024 + KSK/1024
+ MAX 12 KSK + 2 ZSK at 3943
+ 11 KSK + 4 ZSK at 3930
+ 10 KSK + 6 ZSK at 3917
+ 8 KSK + 10 ZSK at 3891
+
+ ZSK/1024 + KSK/1536
+ MAX 8 KSK + 3 ZSK at 3900
+ 7 KSK + 6 ZSK at 3904
+ 6 KSK + 9 ZSK at 3908
+
+ ZSK/1024 + KSK/2048
+ MAX 6 KSK + 4 ZSK at 3951
+ 5 KSK + 8 ZSK at 3972
+ 4 KSK + 12 ZSK at 3993
+
+ Note that these are just examples and this document is not making
+ any recommendations on suitable choices of either key lengths nor
+ number of different keys employed at a security apex.
+
+ This document does however, based upon the above figures, make the
+ recommendation that at a security apex that expects to distribute
+ "trusted keys" the KEY RRset should only be signed with the KSKs
+ and not with the ZSKs to keep the size of the response packets
+ down.
+
+
+5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
+
+ In DNSSEC according to RFC2535[RFC2535] validation is the process
+ of tracing a chain of signatures (and keys) upwards through the DNS
+ hierarchy until a "trusted key" is reached. If there is a known
+ trusted key present at a security apex above the starting point
+ validation becomes an exercise with a binary outcome: either the
+ validation succeeds or it fails. No intermediate states are
+ possible.
+
+ With multiple "trusted keys" (i.e. the KEY RRset for the security
+ apex signed by multiple KSKs) this changes into a more complicated
+ space of alternatives. From the perspective of complexity that may
+ be regarded as a change for the worse. However, from a perspective
+ of maximizing available trust the multiple KSKs add value to the
+ system.
+
+5.1. Possible to do Threshold Validation
+
+ With multiple KSKs a new option that opens for the security
+ concious resolver is to not trust a key individually. Instead the
+ resolver may decide to require the validated signatures to exceed a
+ threshold. For instance, given M trusted keys it is possible for
+ the resolver to require N-of-M signatures to treat the data as
+ validated.
+
+ I.e. with the following pseudo-configuration in a validating
+ resolver
+
+ security-apex "." IN {
+ keys { ksk-1 .... ;
+ ksk-2 .... ;
+ ksk-3 .... ;
+ ksk-4 .... ;
+ ksk-5 .... ;
+ };
+ validation {
+ # Note that ksk-4 is not present below
+ keys { ksk-1; ksk-2; ksk-3; ksk-5; };
+ # 3 signatures needed with 4 possible keys, aka 75%
+ needed-signatures 3;
+ };
+ };
+
+ we configure five trusted keys for the root zone, but require two
+ valid signatures for the top-most KEY for validation to
+ succeed. I.e. threshold validation does not force multiple
+ signatures on the entire signature chain, only on the top-most
+ signature, closest to the security apex for which the resolver has
+ trusted keys.
+
+5.2. Not All Trusted Keys Will Be Available
+
+ With multiple KSKs held and managed by separate entities the end
+ resolvers will not always manage to get access to all possible
+ trusted keys. In the case of just a single KSK this would be fatal
+ to validation and necessary to avoid at whatever cost. But with
+ several fully trusted keys available the resolver can decide to
+ trust several of them individually. An example based upon more
+ pseudo-configuration:
+
+ security-apex "." IN {
+ keys { ksk-1 .... ;
+ ksk-2 .... ;
+ ksk-3 .... ;
+ ksk-4 .... ;
+ ksk-5 .... ;
+ };
+ validation {
+ # Only these two keys are trusted independently
+ keys { ksk-1; ksk-4; };
+ # With these keys a single signature is sufficient
+ needed-signatures 1;
+ };
+ };
+
+ Here we have the same five keys and instruct the validating
+ resolver to fully trust data that ends up with just one signature
+ from by a fully trusted key.
+
+ The typical case where this will be useful is for the case where
+ there is a risk of the resolver not catching a rollover event by
+ one of the KSKs. By doing rollovers of different KSKs with
+ different schedules it is possible for a resolver to "survive"
+ missing a rollover without validation breaking. This improves
+ overall robustness from a management point of view.
+
+5.3. Not All Possible KSKs Need to Be Trusted
+
+ With just one key available it simply has to be trusted, since that
+ is the only option available. With multiple KSKs the validating
+ resolver immediately get the option of implementing a local policy
+ of only trusting some of the possible keys.
+
+ This local policy can be implemented either by simply not
+ configuring keys that are not trusted or, possibly, configure them
+ but specify to the resolver that certain keys are not to be
+ ultimately trusted alone.
+
+
+6. Additional Benefits from Having Multiple KSKs
+
+6.1. More Robust Key Rollovers
+
+ With only one KSK the rollover operation will be a delicate
+ operation since the new trusted key needs to reach every validating
+ resolver before the old key is retired. For this reason it is
+ expected that long periods of overlap will be needed.
+
+ With multiple KSKs this changes into a system where different
+ "series" of KSKs can have different rollover schedules, thereby
+ changing from one "big" rollover to several "smaller" rollovers.
+
+ If the resolver trusts several of the available keys individually
+ then even a failure to track a certain rollover operation within
+ the overlap period will not be fatal to validation since the other
+ available trusted keys will be sufficient.
+
+6.2. Evaluation of Multiple Key Distribution Mechanisms
+
+ Distribution of the trusted keys for the DNS root zone is
+ recognized to be a difficult problem that ...
+
+ With only one trusted key, from one single "source" to distribute
+ it will be difficult to evaluate what distribution mechanism works
+ best. With multiple KSKs, held by separate entitites it will be
+ possible to measure how large fraction of the resolver population
+ that is trusting what subsets of KSKs.
+
+
+7. Security Considerations
+
+ From a systems perspective the simplest design is arguably the
+ best, i.e. one single holder of both KSK and ZSKs. However, if that
+ is not possible in all cases a more complex scheme is needed where
+ additional trust is injected by using multiple KSK holders, each
+ contributing trust, then there are only two alternatives
+ available. The first is so called "split keys", where a single key
+ is split up among KSK holders, each contributing trust. The second
+ is the multiple KSK design outlined in this proposal.
+
+ Both these alternatives provide for threshold mechanisms. However
+ split keys makes the threshold integral to the key generating
+ mechanism (i.e. it will be a property of the keys how many
+ signatures are needed). In the case of multiple KSKs the threshold
+ validation is not a property of the keys but rather local policy in
+ the validating resolver. A benefit from this is that it is possible
+ for different resolvers to use different trust policies. Some may
+ configure threshold validation requiring multiple signatures and
+ specific keys (optimizing for security) while others may choose to
+ accept a single signature from a larger set of keys (optimizing for
+ redundancy). Since the security requirements are different it would
+ seem to be a good idea to make this choice local policy rather than
+ global policy.
+
+ Furthermore, a clear issue for validating resolvers will be how to
+ ensure that they track all rollover events for keys they
+ trust. Even with operlap during the rollover (which is clearly
+ needed) there is still a need to be exceedingly careful not to miss
+ any rollovers (or fail to acquire a new key) since without this
+ single key validation will fail. With multiple KSKs this operation
+ becomes more robust, since different KSKs may roll at different
+ times according to different rollover schedules and losing one key,
+ for whatever reason, will not be crucial unless the resolver
+ intentionally chooses to be completely dependent on that exact key.
+
+8. IANA Considerations.
+
+ NONE.
+
+
+9. References
+
+9.1. Normative.
+
+ [RFC2535] Domain Name System Security Extensions. D. Eastlake.
+ March 1999.
+
+ [RFC3090] DNS Security Extension Clarification on Zone Status.
+ E. Lewis. March 2001.
+
+
+9.2. Informative.
+
+ [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
+ (DNS). D. Eastlake 3rd. May 2001.
+
+ [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad.
+ December 2001.
+
+ [DS] Delegation Signer Resource Record.
+ O. Gudmundsson. October 2002. Work In Progress.
+
+10. Acknowledgments.
+
+ Bill Manning came up with the original idea of moving complexity
+ from the signing side down to the resolver in the form of threshold
+ validation. I've also had much appreciated help from (in no
+ particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
+ Olaf Kolkman.
+
+
+11. Authors' Address
+Johan Ihren
+Autonomica AB
+Bellmansgatan 30
+SE-118 47 Stockholm, Sweden
+johani@autonomica.se
diff --git a/doc/draft/draft-kato-dnsop-local-zones-00.txt b/doc/draft/draft-kato-dnsop-local-zones-00.txt
new file mode 100644
index 0000000..d857cd9
--- /dev/null
+++ b/doc/draft/draft-kato-dnsop-local-zones-00.txt
@@ -0,0 +1,295 @@
+
+
+
+Internet Engineering Task Force Akira Kato, WIDE
+INTERNET-DRAFT Paul Vixie, ISC
+Expires: August 24, 2003 February 24, 2003
+
+
+ Operational Guidelines for "local" zones in the DNS
+ draft-kato-dnsop-local-zones-00.txt
+
+Status of this Memo
+
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026.
+
+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.''
+
+To view the list Internet-Draft Shadow Directories, see
+http://www.ietf.org/shadow.html.
+
+Distribution of this memo is unlimited.
+
+The internet-draft will expire in 6 months. The date of expiration will
+be August 24, 2003.
+
+
+Abstract
+
+A large number of DNS queries regarding to the "local" zones are sent
+over the Internet in every second. This memo describes operational
+guidelines to reduce the unnecessary DNS traffic as well as the load of
+the Root DNS Servers.
+
+1. Introduction
+
+While it has yet been described in a RFC, .local is used to provide a
+local subspace of the DNS tree. Formal delegation process has not been
+completed for this TLD. In spite of this informal status, .local has
+been used in many installations regardless of the awareness of the
+users. Usually, the local DNS servers are not authoritative to the
+.local domain, they end up to send queries to the Root DNS Servers.
+
+There are several other DNS zones which describe the "local"
+information. .localhost has been used to describe the localhost for
+more than a couple of decades and virtually all of the DNS servers are
+configured authoritative for .localhost and its reverse zone .127.in-
+
+
+KATO Expires: August 24, 2003 [Page 1]
+
+
+DRAFT DNS local zones February 2003
+
+addr.arpa. However, there are other "local" zones currently used in the
+Internet or Intranets connected to the Internet through NATs or similar
+devices.
+
+At a DNS server of an university in Japan, half of the DNS queries sent
+to one of the 13 Root DNS Servers were regarding to the .local. At
+another DNS Server running in one of the Major ISPs in Japan, the 1/4
+were .local. If those "local" queries are able to direct other DNS
+servers than Root, or they can be resolved locally, it contributes the
+reduction of the Root DNS Servers.
+
+2. Rationale
+
+Any DNS queries regarding to "local" names should not be sent to the DNS
+servers on the Internet.
+
+3. Operational Guidelines
+
+Those queries should be processed at the DNS servers internal to each
+site so that the severs respond with NXDOMAIN rather than sending
+queries to the DNS servers outside.
+
+The "local" names have common DNS suffixes which are listed below:
+
+3.1. Local host related zones:
+
+Following two zones are described in [Barr, 1996] and .localhost is also
+defined in [Eastlake, 1999] .
+
+ o .localhost
+ o .127.in-addr.arpa
+
+
+Following two zones are for the loopback address in IPv6 [Hinden, 1998]
+. While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
+2001] , the old TLD .int has been used for this purpose for years
+[Thomson, 1995] and many implementations still use .int. So it is
+suggested that both zones should be provided for each IPv6 reverse
+lookup zone for a while.
+
+ o 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.int
+ o 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
+
+
+3.2. Locally created name space
+
+While the use of .local has been proposed in several Internet-Drafts, it
+has not been described in any Internet documents with formal status.
+However, the amount of the queries for .local is much larger than
+others, it is suggested to resolve the following zone locally:
+
+
+
+
+KATO Expires: August 24, 2003 [Page 2]
+
+
+DRAFT DNS local zones February 2003
+
+ o .local
+
+
+
+3.3. Private or site-local addresses
+
+The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
+local addresses [Hinden, 1998] should be resolved locally:
+
+ o 10.in-addr.arpa
+ o 16.172.in-addr.arpa
+ o 17.172.in-addr.arpa
+ o 18.172.in-addr.arpa
+ o 19.172.in-addr.arpa
+ o 20.172.in-addr.arpa
+ o 21.172.in-addr.arpa
+ o 22.172.in-addr.arpa
+ o 23.172.in-addr.arpa
+ o 24.172.in-addr.arpa
+ o 25.172.in-addr.arpa
+ o 26.172.in-addr.arpa
+ o 27.172.in-addr.arpa
+ o 28.172.in-addr.arpa
+ o 29.172.in-addr.arpa
+ o 30.172.in-addr.arpa
+ o 31.172.in-addr.arpa
+ o 168.192.in-addr.arpa
+ o c.e.f.ip6.int
+ o d.e.f.ip6.int
+ o e.e.f.ip6.int
+ o f.e.f.ip6.int
+ o c.e.f.ip6.arpa
+ o d.e.f.ip6.arpa
+ o e.e.f.ip6.arpa
+ o f.e.f.ip6.arpa
+
+
+3.4. Link-local addresses
+
+The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
+1998] should be resolved locally:
+
+ o 254.169.in-addr.arpa
+ o 8.e.f.ip6.int
+ o 9.e.f.ip6.int
+ o a.e.f.ip6.int
+ o b.e.f.ip6.int
+ o 8.e.f.ip6.arpa
+ o 9.e.f.ip6.arpa
+ o a.e.f.ip6.arpa
+ o b.e.f.ip6.arpa
+
+
+
+KATO Expires: August 24, 2003 [Page 3]
+
+
+DRAFT DNS local zones February 2003
+
+4. Suggestions to developers
+
+4.1. Suggestions to DNS software implementors
+
+In order to avoid unnecessary traffic, it is suggested that DNS software
+implementors provide configuration templates or default configurations
+so that the names described in the previous section are resolved locally
+rather than sent to other DNS servers in the Internet.
+
+4.2. Suggestions to developers of NATs or similar devices
+
+There are many NAT or similar devices available in the market.
+Regardless of the availability of DNS Servers in those devices, it is
+suggested that those devices are able to filter the DNS traffic or
+respond to the DNS traffic related to "local" zones by configuration
+regardless of its ability of DNS service. It is suggested that this
+functionality is activated by default.
+
+5. IANA Consideration
+
+While .local TLD has yet defined officially, there are substantial
+queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
+traffic sent to the Root DNS Servers are related to the .local zone.
+Therefore, while it is not formally defined, it is suggested that IANA
+delegates .local TLD to an organization.
+
+The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
+address and the link-local address. It has several DNS server instances
+around the world by using BGP Anycast [Hardie, 2002] . So the AS112
+Project is one of the candidates to host the .local TLD.
+
+Authors' addresses
+
+ Akira Kato
+ The University of Tokyo, Information Technology Center
+ 2-11-16 Yayoi Bunkyo
+ Tokyo 113-8658, JAPAN
+ Tel: +81 3-5841-2750
+ Email: kato@wide.ad.jp
+
+
+ Paul Vixie
+ Internet Software Consortium
+ 950 Charter Street
+ Redwood City, CA 94063, USA
+ Tel: +1 650-779-7001
+ Email: vixie@isc.org
+
+
+
+
+
+
+
+KATO Expires: August 24, 2003 [Page 4]
+
+
+DRAFT DNS local zones February 2003
+
+References
+
+To be filled
+
+References
+
+Barr, 1996.
+D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
+(February 1996).
+
+Eastlake, 1999.
+D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).
+
+Hinden, 1998.
+R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
+RFC2373 (July 1998).
+
+Bush, 2001.
+R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).
+
+Thomson, 1995.
+S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
+RFC1886 (December 1995).
+
+Rekhter, 1996.
+Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
+"Address Allocation for Private Internets" in RFC1918 (February 1996).
+
+IANA, 2002.
+IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).
+
+Vixie, .
+P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.
+
+Hardie, 2002.
+T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
+Addresses" in RFC3258 (April 2002).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+KATO Expires: August 24, 2003 [Page 5]
+
diff --git a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
new file mode 100644
index 0000000..f9eaf26
--- /dev/null
+++ b/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
@@ -0,0 +1,1830 @@
+
+
+
+ INTERNET-DRAFT S. Daniel Park
+ Expires: October 2003 Syam Madanapalli
+ File: SAMSUNG Electronics
+ draft-park-ipv6-extensions-dns-pnp-00.txt April 2003
+
+
+
+
+ IPv6 Extensions for DNS Plug and Play
+
+
+
+ Status of This Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ 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.
+
+
+
+ Abstract
+
+ This document proposes automatic configuration of domain name (FQDN)
+ for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as
+ a part of IPv6 plug and play feature. 6DNAC allows the automatic
+ registration of domain name and corresponding IPv6 Addresses with
+ the DNS server. In order to provide 6DNAC function, Neighbor Discovery
+ Protocol [2461] will be used. Moreover, 6DNAC does not require any
+ changes to the existing DNS system.
+
+
+ Table of Contents
+
+ 1. Introduction ............................................. 3
+ 2. Terminology .............................................. 3
+ 3. 6DNAC Design Principles .................................. 4
+ 4. 6DNAC Overview ........................................... 4
+ 5. 6DNAC Requirements ....................................... 5
+ 5.1. 6DANR Client Requirements ................................ 5
+ 5.2. 6DNAC Server Requirements ................................ 6
+
+Park & Madanapalli Expires October 2003 [Page 1]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 6. 6DNAC Messages and Option Formats ........................ 6
+ 6.1. Router Advertisement (RA) Message Format ................. 6
+ 6.2. Neighbor Solicitation (NS) Message Format ................ 7
+ 6.3. Neighbor Advertisement (NA) Message Format ............... 8
+ 6.4. Option Formats ........................................... 8
+ 6.4.1. DNS Zone Suffix Information Option Format ................ 8
+ 6.4.2. Domain Name (FQDN) Option Format ......................... 9
+ 6.4.3. Router Alert Option for 6DNAC ............................ 10
+ 7. 6DNAC Operation .......................................... 10
+ 7.1. 6DNAC Network Topology ................................... 11
+ 7.2. 6DNAC Operational Scenarios .............................. 12
+ 7.2.1. Domain Name Registration-Success Case .................... 12
+ 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2.... 14
+ 7.2.3. Domain Name Registration-Defend Case ..................... 16
+ 7.2.4. Domain Name Registration in Retry Mode ................... 19
+ 7.2.5. Domain Name Registration when DAD Fails .................. 20
+ 7.3. DNS Zone Suffix Discovery and FQDN Construction .......... 22
+ 7.3.1. Sending Router Advertisement Messages .................... 22
+ 7.3.2. Processing Router Advertisement Messages ................. 22
+ 7.3.3. FQDN Lifetime expiry ..................................... 23
+ 7.3.4. Host Naming Algorithm .................................... 23
+ 7.4. Duplicate Domain Name Detection .......................... 23
+ 7.4.1. DAD with All Nodes Multicast Address ..................... 24
+ 7.4.1.1. Sending Neighbor Solicitation Messages ................... 24
+ 7.4.1.2. Processing Neighbor Solicitation Messages ................ 24
+ 7.4.1.3. Sending Neighbor Advertisement Messages .................. 25
+ 7.4.1.4. Processing Neighbor Advertisement Messages ............... 25
+ 7.4.1.5. Pros and Cons ............................................ 25
+ 7.4.2. DAD with Router Alert Option for 6DNAC ................... 25
+ 7.4.2.1. Sending Neighbor Solicitation Messages ................... 25
+ 7.4.2.2. Processing Neighbor Solicitation Messages ................ 26
+ 7.4.2.3. Sending Neighbor Advertisement Messages .................. 26
+ 7.4.2.4. Processing Neighbor Advertisement Messages ............... 26
+ 7.4.2.5. Pros and Cons ............................................ 26
+ 7.4.3. Explicit Detection of Duplicate Domain Name .............. 26
+ 7.4.3.1. Sending Neighbor Solicitation Messages ................... 26
+ 7.4.3.2. Processing Neighbor Solicitation Messages ................ 26
+ 7.4.3.3. Sending Neighbor Advertisement Messages .................. 27
+ 7.4.3.4. Processing Neighbor Advertisement Messages ............... 27
+ 7.4.3.5. Pros and Cons ............................................ 27
+ 7.4.4. Retry Mode for Re-registering Domain Name ................ 27
+ 7.5. Domain Name Registration ................................. 27
+ 8. Security Consideration ................................... 27
+ 9. IANA Consideration ....................................... 28
+ 10. Acknowledgement .......................................... 28
+ 11. Intellectual Property .................................... 28
+ 12. Copyright ................................................ 28
+ 13. References ............................................... 29
+ 14. Author's Addresses ....................................... 30
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 2]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 1. Introduction
+
+ Today, most networks use DNS[1034][1035] for convenience. In case of
+ IPv6, DNS is more important element because of IPv6 long addresses
+ which are difficult to remember. In addition, small networks like home
+ networks using IPv6, should be able to make network easily without
+ manual configuration. Also, these small networks may not have DHCP
+ Server, DNS Server etc. that are used to configure the network. This
+ document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure
+ for generating and registering the Domain Name and IPv6 addresses with
+ the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are
+ required to implement lightweight functions specified in this document.
+ 6DNAC can be applied to all defined IPv6 unicast addresses except Link
+ local IPv6 addresses, viz: Site-local and Global addresses.
+
+ 6DNAC uses Neighbor Discovery Protocol [2461] with new additions
+ (defined in section 6) and DAD procedures for generating and
+ registering the Domain Name with the DNS server automatically.
+
+
+ 2. Terminology
+
+ 6DNAC - IPv6 Domain Name Auto Configuration. It can provide
+ IPv6 hosts with Domain Name Generation and
+ Registration automatically.
+
+ 6DNAC Client - An IPv6 node that can generate its own unique Domain
+ Name. Section 3 identifies the new requirements that
+ 6DNAC places on an IPv6 node to be a 6DNAC node.
+
+ 6DNAC Server - An IPv6 node that can collect and registrate Domain
+ Name and IPv6 addresses automatically. 6DNAC server
+ uses the information from the DAD operation messages
+ with newly defined options for the registration of the
+ Domain Name and IPv6 Addresses. Section 3 identifies
+ the new requirements that 6DNAC places on an IPv6
+ node to be a 6DNAC server. Also 6DNAC server can have
+ various other functions depending on network
+ environment and the network operator. For instance
+ 6DNAC Server can acts as a Gateway as well Home Server
+ in Home Networks.
+
+ DAD - Duplicate Address Detection (is defined [2461])
+
+ DFQDND - Duplicate Domain Name Detection
+
+ FQDN - Fully Qualified Domain Name - FQDN and Domain Name are
+ used interchangeably in this document.
+
+ NA - Neighbor Advertisement message (is defined [2461])
+
+ NS - Neighbor Solicitation message (is defined [2461])
+
+ RA - Router Advertisement message (is defined [2461])
+
+ SLAAC - Stateless Address Autoconfiguration [2462].
+
+Park & Madanapalli Expires October 2003 [Page 3]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 3. 6DNAC Design Principles
+
+ This section discusses the design principles of 6DNAC mechanism.
+
+ 1. The new procedures for plug and play DNS should not cause changes
+ to existing DNS system. 6DNAC requires lightweight functions to be
+ implemented only at the client side of the DNS system, and uses the
+ existing DDNS UPDATE [2136] to communicate with DNS Servers.
+
+ 2. Introducing a new protocol will always introduce new problems.
+ 6DNAC uses the existing protocols NDP [2461] with minor extensions
+ for generating and registering the domain name automatically
+ without defining a new protocol
+
+ 3. Reusing proven and well understood design principles/patterns
+ will always yield a robust system. 6DNAC is based on IPv6 Address
+ Auotoconfiguration principle, where routers advertise the prefix
+ and host adds the interface ID to the prefix and forms the IPv6
+ address. Domain Name (FQDN) also contains two parts: host name
+ and DNS zone suffix. Routers can advertise the DNS zone suffix
+ on a particular link in Router Advertisements (RA Messages) and
+ hosts can prefix their preferred host name to the DNS zone suffix
+ and form the fully qualified domain name. Also the detection of
+ duplicate domain name is similar to Duplicate Address Detection
+ (DAD) and can be part of DAD operation itself.
+
+
+ 4. 6DNAC Overview
+
+ 6DNAC proposes minor extensions to NDP [2461] for automatic generation
+ and registration of domain name with the DNS server. It introduces two
+ new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone
+ Suffix option is carried in Router Advertisement (RA) messages for
+ notifying IPv6 nodes about the valid DNS Zone Suffix on the link and
+ FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement
+ (NA) messages to detect duplicate domain name. 6DNAC consists of two
+ components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the
+ domain name based on DNS Zone Suffix using Host Naming Algorithm (see
+ section 7.3.1) and 6DNAC Server collects and registers the DNS
+ information with the DNS Server on behalf of 6DNAC Clients.
+
+ The automatic configuration of domain name using 6DNAC consists of
+ three parts.
+
+ - DNS Zone Suffix Discovery and FQDN Construction:
+
+ IPv6 Nodes collect DNS Zone Suffix information from Router
+ Advertisements and constructs FQDN by prefixing host name to the
+ DNS Zone Suffix. The IPv6 Nodes are required to implement Host
+ Naming Algorithm for generating host part of the FQDN in the
+ absence of administrator.
+
+ Generation of node's FQDN within the node itself has advantages. Nodes
+ can provide forward and reverse name lookups independent of the DNS
+ System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain
+ Name is some thing that is owned by the node.
+
+Park & Madanapalli Expires October 2003 [Page 4]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ - Duplicate Domain Name Detection
+
+ All nodes are expected to go for DAD for all new IPv6 unicast
+ addresses, regardless of whether they are obtained through
+ stateful, stateless or manual configuration. 6DNAC uses the DAD
+ messages with new option for carrying the Domain Name along with
+ the new IPv6 Address. 6DNAC Server captures this information and
+ updates DNS Server provided that the IPv6 Address and its domain
+ name are not duplicate. If the domain name is already in use,
+ the 6DNAC server replies to the sender with FQDN Option in NA
+ message indicating that the domain name is duplicate. Then the
+ node is expected to generate another domain name using host
+ naming algorithm and go for DAD. This time the DAD is only for
+ duplicate domain name detection (DFQDND). In order to avoid
+ confusion with the normal NDP processing, the target address
+ field of the NS message must carry the unspecified address
+ in retry mode. This can be repeated depending on number of
+ retries defined by the administrator in the host naming algorithm.
+
+
+ - Domain Name Registration
+
+ 6DNAC Server detects the DNS information (IPv6 Address and
+ corresponding FQDN) from DAD/DFQDND messages and updates DNS
+ Server using existing protocol DDNS UPDATE [2136] provided that
+ the IPv6 Address and its domain name are not duplicate.
+
+ If an IPv6 Address is duplicate, the IPv6 node cannot perform
+ stateless address autoconfiguration repeatedly. Unlike IPv6 stateless
+ address autoconfiguration, 6DNAC allows the automatic configuration of
+ domain name repeatedly if the domain name is duplicate depending on
+ number of retries defined by the administrator in the host naming
+ algorithm.
+
+
+ 5. 6DNAC Requirements
+
+ Depending on the 6DNAC functionality, the IPv6 nodes implement, they
+ are called either 6DNAC Clients or 6DNAC Servers. The following
+ sections lists the requirements that the 6DNAC Client and 6DNAC server
+ must support.
+
+
+ 5.1. 6DANC Client Requirements
+
+ - 6DNAC Client must recognize and process the following NDP
+ extensions
+
+ - DNS Zone Suffix option in RA messages for generating its
+ domain name (FQDN).
+
+ - Domain Name option in NS and NA messages for detecting
+ the duplicate domain name
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 5]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ - It must generate its domain name (FQDN) based on the DNS
+ suffix that it got from the router advertisement. And it must
+ have a host naming algorithm for generating the host part of
+ the FQDN.
+
+ - If NA message is received with unspecified target address and
+ FQDN option, then the node must treat that the domain is
+ duplicate.
+
+
+ 5.2. 6DNAC Server Requirements
+
+ - 6DNAC Server must recognize and process the following NDP
+ extensions
+
+ - If the 6DNAC Server is a router on the link, then it
+ must advertise DNS Zone Suffix option in RA messages
+ for hosts to generate their domain name (FQDN).
+
+ - FQDN option in NS messages for detecting new DNS
+ information for of nodes on the link for which it
+ must update the AAAA RR and PTR RR in DNS Server.
+
+ - FQDN option in NA messages for notifying duplicate
+ domain name with unspecified target address.
+
+ - 6DNAC server must update the DNS Server (both AAAA RR and
+ PTR RR) dynamically using DDNS UPDATE [2136].
+
+ - 6DNAC server must cache this (newly detected) FQDN, Link
+ Layer Address, and IPv6 Address information, so that it can
+ decide whether it really needs to update DNS Server or not,
+ to avoid redundant updates. This information will also be
+ used for notifying the duplicate domain name.
+
+
+ 6. 6DNAC Messages and Option Formats
+
+ In order to achieve the plug and play DNS, 6DNAC proposes new
+ extensions to the NDP [2461]. This section specifies the new
+ additions to NDP messages and formats of new options.
+
+
+ 6.1. Router Advertisement (RA) Message Format
+
+ Routers send out Router Advertisement (RA) message periodically, or
+ in response to a Router Solicitation. 6DNAC does not modify the format
+ of the RA message, but proposes new option (DNS Zone Suffix Information)
+ to be carried in RA messages.
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 6]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 0 1 2 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Cur Hop Limit |M|O| Reserved | Router Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reachable Time |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Retrans Timer |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ... |
+ / /
+ | DNS Zone Suffix Information |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 1 RA message>
+
+
+
+ 6.2. Neighbor Solicitation (NS) Message Format
+
+ 6DNAC does not modify the format of the Neighbor Solicitation (NS)
+ message, but proposes new option (FQDN Option) to be carried in NS
+ messages. When a node is going for DAD, the node must include FQDN
+ option in NS message to participate in plug and play DNS. If the
+ node is going for Explicit Detection of Duplicate Domain Name, the
+ node must use FQDN option in NS message and unspecified address in
+ the target address field.
+
+
+ 0 1 2 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Target Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ... |
+ / /
+ | Domain Name |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 2 NS message>
+
+Park & Madanapalli Expires October 2003 [Page 7]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 6.3. Neighbor Advertisement (NA) Message Format
+
+ 6DNAC does not modify the format of the Neighbor Advertisement (NA)
+ message, but proposes new option (FQDN Option) to be carried in NA
+ messages. 6DNAC Server sends NA message with FQDN option to 6DNAC
+ Client that is performing duplicate domain name detection in case
+ the domain name found to be duplicate.
+
+ 0 1 2 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Code | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |R|S|O| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + Target Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Options ... |
+ / /
+ | FQDN Option |
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 3 NA message>
+
+
+ 6.4 Option Formats
+
+ 6.4.1. DNS Zone Suffix Information Option Format
+
+ IPv6 nodes require DNS Zone Suffix for constructing their FQDN.
+ 6DNAC introduces new option for routers to advertise the DNS Zone
+ Suffix Information for IPv6 nodes on the link. The suffix information
+ should be configured into routers manually.
+
+ 0 1 2 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Valid Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ / DNS Zone Suffix /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 4 DNS Zone Suffix Information>
+
+Park & Madanapalli Expires October 2003 [Page 8]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ Type [TBD]
+
+ Length 8-bit unsigned integer. The length of the option
+ (including the type and length fields) in units of
+ 8 octets.
+
+ Reserved This field is unused. It must be initialized to zero
+ by the sender and must be ignored by the receiver.
+
+ Valid Life Time 32-bit signed integer. The maximum time, in
+ seconds, over which this suffix is valid. Nodes
+ should treat this as the life time for their domain
+ name. Nodes should contact the source of this
+ information before expiry of this time interval.
+ A value of all one bits (0xFFFFFFFF) represents
+ infinity.
+
+ DNS Zone Suffix The suffix part of the FQDN. The data in the DNS
+ Zone Suffix field should be encoded according to
+ DNS encoding rules specified in [1035].
+
+
+
+ 6.4.2. Domain Name (FQDN) Option Format
+
+
+ 0 1 2 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type | Length | Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Valid Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + +
+ | |
+ + FQDN Target Address +
+ | |
+ + +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ / Domain Name /
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ <Figure: 5 FQDN Information>
+
+ Type [TBD]
+
+ Length 8-bit unsigned integer. The length of the option
+ (including the type and length fields) in units
+ of 8 octets. It must be greater than 3.
+
+
+
+Park & Madanapalli Expires October 2003 [Page 9]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ Reserved This field is unused. It must be initialized to
+ zero by the sender and must be ignored by the
+ receiver.
+
+ Valid Life Time 32-bit signed integer. The maximum time, in
+ seconds, over which this domain name is valid
+ 6DNAC should deregister this domain name at
+ the expiry of this interval. 6DNAC clients
+ should send updates by the expiry of this
+ interval. A value of all one bits (0xFFFFFFFF)
+ represents infinity.
+
+ FQDN Target Address The Address for which the FQDN maps to. It
+ should be same as Target Address field of the
+ NS message in case of DAD & duplicate FQDN are
+ running in parallel.
+
+ Domain Name The domain name (FQDN) of the node. The data in
+ the domain name should be encoded according to
+ DNS encoding rules specified in [1035].
+
+
+ 6.4.3. Router Alert Option for 6DNAC
+
+ Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop
+ Header for using in NDP messages. The presence of this option in NS
+ message informs the router that this NS message is carrying Domain
+ Name information and must be processed by the 6DNAC Server on the router.
+ 6DNAC Clients can use this option for sending DAD packets instead
+ of addressing the DAD packets to the all-nodes multicast address
+ when 6DNAC Server is implemented on router.
+
+ The Router Alert option has the following format:
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Length = 2
+
+ Values are registered and maintained by the IANA. For 6DNAC, the
+ value has to be assigned by IANA.
+
+ Further information about this option can be obtained from
+ IPv6 Router Alert Option [2711].
+
+
+ 7. 6DNAC Operation
+
+ 6DNAC provides mechanisms for automatic generation of domain name
+ and registering it with the DNS Server for IPv6 nodes. 6DNAC consists
+ of two components: 6DNAC Client and 6DNAC Server. All nodes that want
+ to participate in plug and play DNS are required to implement 6DNAC
+ Client functionality, and one of the IPv6 nodes is required to
+ implement 6DNAC Server functionality. The IPv6 node that implements
+ the 6DNAC Server functionality must know the location of the DNS
+ Server and must be a trusted node to send DDNS UPDATE [2136] messages.
+
+Park & Madanapalli Expires October 2003 [Page 10]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 7.1. 6DNAC Network Topology
+
+ This section identifies the possible locations for the 6DNAC Server.
+ Note that, all nodes are required to implement 6DNAC Client
+ functionality for constructing the domain name from the DNS Zone
+ Suffix Information advertised by the router. Figure 6 illustrates
+ IPv6 host (H4) implementing 6DNAC Server functionality. In this case
+ H4 can serve only one link (that it belongs to) for automatic
+ registration of domain name. H4 must observe the DAD packets on the
+ link to detect the DNS information, this requires all nodes on the
+ link must belong to same solicited node multicast address. In general,
+ this may not be the case. So the node that is going for DAD must use
+ all nodes multicast address for DAD packets, so that the 6DNAC Server
+ (H4) can observe the DAD packets, detects IPv6 address and
+ corresponding domain name, checks if this domain name is duplicate
+ and finally registers the domain name with the DNS Server.
+
+
+ 6DNAC Server
+ +---+ +---+ +----------+
+ | H1| | H4|<--- DDNS UPDATE --->|DNS Server|
+ +-+-+ +-+-+ +----+-----+
+ | | +----+ +---/
+ | | | | /
+ ---+-----+-----------+-----+-----------+ R1 +-----+
+ | | | |
+ | | +----+
+ +-+-+ +-+-+
+ | H2| | H3|
+ +---+ +---+
+
+
+ H1, H2, H3 - 6DNAC Clients
+ H4 - 6DNAC Server
+ R1 - Router
+
+
+ <Figure: 6 Example of 6DNAC Topology>
+
+
+ Figure 7 shows the 6DNAC Server implemented on a router R1. In this
+ case a single 6DNAC server can serve multiple links for automatic
+ configuration of the domain name. This topology also has flexibility
+ of using DAD packets with Router Alert option instead of sending DAD
+ packets to all nodes multicast address. The routers are required to
+ process all the packets with Router Alert option as per [2711].
+
+ In case of Home Networks, R1 is will acts as a Home Gateway (CPE)
+ connected to ISP. R1 delegates the prefix from the ISP edge router.
+ After delegating the prefix the CPE can advertise the DNS Zone suffix
+ along with the prefix information to the nodes on the links to which
+ the router is connected to. Note that the R1 must be configured with
+ the DNS Zone suffix Information manually.
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 11]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ +---+ +---+
+ | H3+ | H4|
+ +-+-+ +-+-+
+ | |
+ | LINK2 |
+ +---+ ---+--------+--+-- +----------+
+ | H1| | |DNS Server|
+ +-+-+ | +----+-----+
+ | +--+-+ -------/
+ | LINK 1 | | /
+ ---+-----+------------------+ R1 +---------+
+ | | | DDNS UPDATE
+ | +----+
+ +-+-+ 6DNAC Server
+ | H2|
+ +---+
+
+
+ H1, H2 - 6DNAC Clients on Link1
+ H3, H4 - 6DNAC Clients on Link2
+ R1 - Router with 6DNAC Server, serving both Link1 and Link2
+
+
+ <Figure: 7 Example of 6DNAC Server serving multiple links>
+
+
+ 7.2. 6DNAC Operational Scenarios
+
+ This section provides message sequence charts for various 6DNAC
+ operational scenarios assuming that the 6DNAC Server is implemented
+ on a router. All the scenarios assume that the normal boot up time
+ stateless address autoconfiguration of Link Local address derived
+ from the Interface Identifier has been completed successfully. And
+ it is also assumed that the router is already configured with the
+ DNS Zone Suffix Information.
+
+
+ Legend:
+
+ 6DNAC-A, B, C : 6DNAC Clients
+ 6DNAC-S : 6DNAC Server/Router
+ DAD : Duplicate Address Detection
+ DFQDND : Duplicate Domain Name Detection
+ DNS-S : DNS Server
+
+
+ 7.2.1. Domain Name Registration-Successful Case
+
+ This scenario starts when a 6DNAC Client receives RA message with
+ DNS Zone Suffix and other parameters including address prefix as
+ specified in NDP [2461] and wants configure its IPv6 address (Global
+ or Site Local) and domain name. It is Assumed that the
+ DupAddrDetectTransmits is set to 1.
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 12]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ +---------+ +---------+ +---------+
+ | 6DNAC-C | | 6DNAC-S | | DNS-S |
+ +----+----+ +----+----+ +----+----+
+ | | |
+ | RA with | |
+ | DNS Suffix Opt | |
+ |<---------------| |
+ | #1 | |
+ |---+ | |
+ Construct |#2 | |
+ FQDN | | |
+ |<--+ | |
+DAD/DFQDND Starts | |
+ | | |
+ | | |
+ | NS With | |
+ | FQDN Opt | |
+ |--------------->| |
+ | #3 | |
+ | | |
+ | |------+ |
+ | Create FQDN | #4 |
+ | <FQDN,C> | |
+ | |<-----+ |
+ | | |
+ | | Register FQDN |
+ | |--------------->|
+ | | #5 |
+ | #6 | |
+ |--------+ | |
+ No Response | | |
+ DFQDND-Success | | |
+ |<-------+ | |
+ | | |
+ | | |
+ v V v
+
+
+ <Figure: 8 Domain Name Generation and Registration>
+
+
+ #1. 6DNAC Server (Router) sends out router advertisement with DNS
+ Suffix information along with other parameters as specified in
+ NDP [2461].
+
+ #2. 6DNAC Client processes the router advertisement and constructs
+ the FQDN by prefixing hostname to the DNS Zone Suffix. It also
+ constructs IPv6 address from the autoconfiguration prefix
+ information option.
+
+ #3. 6DNAC Client starts duplicate address & FQDN detection for the
+ IPv6 address & FQDN constructed and sends out a Neighbor
+ Solicitation message with FQDN option.
+
+ Note that the DAD packets must be addressed to all nodes multicast
+ address if Router Alert option is not used.
+
+Park & Madanapalli Expires October 2003 [Page 13]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #4. 6DNAC Server processes the Neighbor Solicitation message sent by
+ 6DNAC Client as part of duplicate FQDN detection procedure and
+ creates a FQDN entry in its FQDN Cache (assuming that there is no
+ entry <FQDN,C>), where C is Link Layer Address of the 6DNAC Client.
+
+ #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
+ through the existing protocol DDNS UPDATE.
+
+ #6. 6DNAC Client times out and observes that there is no response to
+ defend its duplicate FQDN detection procedure and the node is
+ successful in configuring its domain name.
+
+ Note that, Stateless Address Autoconfiguration DAD procedure is not
+ depicted in the following message sequence chart, which simultaneously
+ happens along with duplicate FQDN detection.
+
+
+ 7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2
+
+ This scenario starts when a 6DNAC Client receives RA message with
+ DNS Zone Suffix and other parameters including address prefix as
+ specified in NDP [2461] and wants configure its IPv6 address (Global
+ or Site Local) and domain name. The node is configured with
+ DupAddrDetectTransmits = 2 for reliability in delivering DAD messages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 14]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ +---------+ +---------+ +---------+
+ | 6DNAC-C | | 6DNAC-S | | DNS-S |
+ +----+----+ +----+----+ +----+----+
+ | | |
+ | RA with | |
+ | DNS Suffix Opt | |
+ |<---------------| |
+ | #1 | |
+ |---+ | |
+ Construct |#2 | |
+ FQDN | | |
+ |<--+ | |
+DAD/DFQDND Starts | |
+ | | |
+ | | |
+ | NS With | |
+ | FQDN Opt | |
+ |--------------->| |
+ | #3 | |
+ | | |
+ | |------+ |
+ | Create FQDN | #4 |
+ | <FQDN,C> | |
+ | |<-----+ |
+ | | |
+ | | Register FQDN |
+ | |--------------->|
+ | | #5 |
+ | NS With | |
+ | FQDN Opt | |
+ |--------------->| |
+ | #6 | |
+ | | |
+ | Lookup FQDN |
+ | Entry exists |
+ | |------+ |
+ | Ignore | #7 |
+ | |<-----+ |
+ | #8 | |
+ |--------+ | |
+ No Response | | |
+ DFQDND-Success | | |
+ |<-------+ | |
+ | | |
+ | | |
+ v V v
+
+
+
+ <Figure: 9 Verification of duplicated Domain Name>
+
+
+ Steps from #1 to #5 are same as that of scenario.7.2.1.
+
+ #6. 6DNAC Client sends out second Neighbor Solicitation message with
+ FQDN option as part of duplicate FQDN detection.
+
+Park & Madanapalli Expires October 2003 [Page 15]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #7. 6DNAC Server receives and observes that the FQDN Cache exactly
+ matches with that of the NS information and ignores the NS message.
+
+ #8. 6DNAC Client times out and observes that there is no response to
+ defend its duplicate FQDN detection procedure and the node is
+ successful in configuring its domain name..
+
+
+ 7.2.3. Domain Name Registration-Defend Case
+
+ This scenario starts when two 6DNAC Client receive RA message with
+ DNS Zone Suffix and other parameters including address prefix as
+ specified in NDP [2461] and both the nodes want configure their IPv6
+ address (Global or Site Local) and domain name. In this scenario both
+ the nodes want to have same domain name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 16]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+
+ +---------+ +---------+ +---------+ +---------+
+ | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S |
+ +----+----+ +----+----+ +----+----+ +----+----+
+ | | | |
+ | RA with | RA with | |
+ | DNS Suffix Opt | DNS Suffix Opt | |
+ |<---------------|--------------->| |
+ | #1 | #1 | |
+ |---+ | |---+ |
+ Construct | #2 | Construct | #2 |
+ FQDN | | FQDN | |
+ |<--+ | |<--+ |
+ DAD/DFQDND Starts | DAD/DFQDND Starts |
+ | | <DELAYED> |
+ | | | |
+ | NS with | | |
+ | FQDN Opt | | |
+ |--------------->| | |
+ | #3 | | |
+ | No Entry | |
+ | |------+ | |
+ | Create FQDN | #4 | |
+ | <FQDN,A> | | |
+ | |<-----+ | |
+ | | | |
+ | | Register FQDN #5 |
+ | |-------------------------------->|
+ | | | |
+ | | NS with | |
+ | | FQDN Opt | |
+ | |<---------------| |
+ | | #6 | |
+ | |------+ | |
+ | FQDN is in use| | |
+ | Defend DFQDND| #7 | |
+ | |<-----+ | |
+ | | | |
+ | | NA with | |
+ | | D-flag Set | |
+ | |--------------->| |
+ | | #8 | |
+ |------+ | |---+ |
+ No Response | #9 | Enter | #10 |
+ DFQDND Success| | Retry Mode| |
+ |<-----+ | |<--+ |
+ | | | |
+ v v v v
+
+
+ <Figure: 10 Multiple Hosts Requesting Same Domain Name>
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 17]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #1. 6DNAC Server (Router) sends out router advertisement with DNS
+ Suffix information.
+
+ #2. 6DNAC Clients A&B process the router advertisement and construct
+ their FQDN by prefixing hostname to the DNS Zone Suffix. They
+ also construct IPv6 address from the autoconfiguration prefix
+ information option.
+
+ When each host is trying to go for DAD, all hosts must have
+ random delay to avoid the traffic congestion according to [2461].
+ So here it is assumed that 6DNAC Client-A starts DAD first and
+ 6DNAC Client-B starts DAD later.
+
+ #3. 6DNAC Client-A starts duplicate address & FQDN detection for the
+ IPv6 address & FQDN constructed and sends out a Neighbor
+ Solicitation message with FQDN option.
+
+ #4. 6DNAC Server processes the Neighbor Solicitation message sent by
+ 6DNAC Client-A as part of duplicate FQDN detection procedure and
+ creates a FQDN entry in its FQDN Cache (assuming that there is no
+ entry <FQDN,A>), where A is Link Layer Address of the 6DNAC Client-A.
+
+ #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
+ through the existing protocol DDNS UPDATE.
+
+ #6. 6DNAC Client-B starts duplicate address & FQDN detection for the
+ IPv6 address & FQDN constructed and sends out a Neighbor Solicitation
+ message with FQDN option.
+
+ #7. 6DNAC Server processes the Neighbor Solicitation message sent by
+ 6DNAC Client-B as part of duplicate FQDN detection procedure and
+ finds that the domain name is already in use by the 6DNAC Client-A.
+ Hence, concludes to defend the duplicate FQDN detection of 6DNAC
+ Client-B.
+
+ #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN
+ option to 6DNAC Client-B to defend its duplicate FQDN detection.
+
+ #9. 6DNAC Client-A times out and observes that there is no response to
+ defend its duplicate FQDN detection procedure and the node is
+ successful in configuring its domain name.
+
+ #10. 6DNAC Client-B observes that there is a NA with FQDN option
+ indicating that the domain name is duplicate and enters Retry
+ Mode. In retry mode, 6DNAC Client constructs another FQDN based
+ on Host Naming Algorithm. The number of retries is defined by the
+ administrator and must be a configurable value.
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 18]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ 7.2.4. Domain Name Registration in Retry Mode
+
+ Pre-Conditions:
+
+ 1. Duplicate Address Detection has succeeded
+ 2. Duplicate FQDN Detection FAILED
+ 3. FQDN is the first FQDN one constructed and FAILED
+ 4. FQDN2 is the second FQDN to be constructed
+ 5. The Neighbor Solicitation in the 'Retry Mode'
+ carries unspecified address in its target field (NS*).
+
+ +---------+ +---------+ +---------+
+ | 6DNAC-C | | 6DNAC-S | | DNS-S |
+ +----+----+ +----+----+ +----+----+
+ | | |
+ |--------+ | |
+ Construct | #1 | |
+ new FQDN2 | | |
+ |<-------+ | |
+ | | |
+ DFQDND Restarts | |
+ | | |
+ | | |
+ | NS* With | |
+ | FQDN Opt | |
+ |--------------->| |
+ | #2 | |
+ | | |
+ | No Entry |
+ | |------+ |
+ | Create FQDN | #3 |
+ | <FQDN2,C> | |
+ | |<-----+ |
+ | | |
+ | | Register FQDN2 |
+ | |--------------->|
+ | | #4 |
+ | | |
+ |--------+ | |
+ No Response | #5 | |
+ DFQDND-Success | | |
+ |<-------+ | |
+ | | |
+ v V v
+
+
+ <Figure: 11 Regeneration of Domain Name>
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 19]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm,
+ the DNS Zone Suffix, and it is FQDN2.
+ #2. It then starts Duplicate Detection only for Domain Name. 6DNAC
+ Client sends out NS with FQDN option and unspecified target
+ address.
+
+ #3. 6DNAC Server processes the Retry Mode NS message and finds that
+ the FQDN2 is not in use and creates Cache entry as <FQDN2, C>.
+
+ #4. It then starts registration procedures with the DNS Server.
+
+ #5. Meanwhile, 6DNAC Client timesout and observes that there is no
+ defending NA for its DFQDND NS sent out and successfully
+ configures its domain name.
+
+
+ 7.2.5. Domain Name Registration when DAD Fails
+
+ Duplicate domain name detection and subsequent registration starts
+ if and only if the DAD for IPv6 address succeeds. If the DAD for
+ IPv6 address fails then no actions are taken for domain name. When
+ DAD fails for stateless address autoconfiguration, then the domain
+ configuration starts only when the address has been configured using
+ Stateful Address Configuration methods and the node is going on DAD
+ for this address.
+
+ This scenario starts when a 6DNAC Client receives RA message with
+ DNS Zone Suffix and other parameters including address prefix as
+ specified in NDP [2461] and wants configure its IPv6 address (Global
+ or Site Local) and domain name.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 20]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ +---------+ +---------+ +---------+ +---------+
+ | 6DNAC-A | | 6DNAC-S | | 6DNAC-B | | DNS-S |
+ +----+----+ +----+----+ +----+----+ +----+----+
+ | | | |
+ | | | |
+ | RA with | | |
+ | DNS Suffix Opt | | |
+ |<---------------| | |
+ | #1 | | |
+ |-----+ | | |
+ Construct | | | |
+ FQDN& | #2 | | |
+ IPv6 Addr | | | |
+ |<----+ | | |
+ DAD/DFQDND Starts | | |
+ | | | |
+ | | | |
+ | NS with | | |
+ | FQDN Opt | | |
+ |--------------->+--------------->| |
+ | #3 | #3 | |
+ | No Entry | |
+ | |------+ | |
+ | Create FQDN | | |
+ | <FQDN,A> | #4 | |
+ | |<-----+ | |
+ | | | |
+ | | |------+ |
+ | | My IPv6 Addr| #5 |
+ | | |<-----+ |
+ | | Defend DAD | |
+ | | with NA | |
+ |<---------------+<---------------| |
+ | #6 | #6 | |
+ | Entry | |
+ | |------+ | |
+ | Delete FQDN | #7 | |
+ | |<-----+ | |
+ | | | |
+ |----+ | | |
+ DAD Failed | #8 | | |
+ Stop DFQDND | | | |
+ |<---+ | | |
+ | | | |
+ v v v v
+
+ <Figure: 12 DAD failure>
+
+ #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A.
+
+ #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and
+ FQDN as per Host Naming Algorithm.
+
+ #3. It then starts Duplicate address & FQDN Detection, for the newly
+ constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS
+ with FQDN option.
+
+Park & Madanapalli Expires October 2003 [Page 21]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+ #4. 6DNAC Server processes the DAD/DFQDND NS message and finds
+ that there is no entry for the FQDN in its cache. And,
+ creates Cache entry as <FQDN, A> and starts a Registration
+ timer with RegistrationWaitTime seconds.
+
+ #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is
+ in its unicast address list.
+
+ #6. It then starts defending DAD by sending NA to all-nodes multicast.
+
+ #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A.
+ And, deletes its FQDN Cache entry <FQDN,A>.
+
+ #8. 6DNAC Client gets defending DAD-NA and desists from DAD.
+ And also, stops Duplicate FQDN Detection as well.
+ At this point the address must be configured using stateful
+ methods and the domain name registration starts with the DAD
+ for the newly constructed IPv6 address.
+
+ 7.3. DNS Zone Suffix Discovery and FQDN Construction
+
+ 7.3.1. Sending Router Advertisement Messages
+
+ Routers send out Router Advertisement message periodically,
+ or in response to a Router Solicitation. Router should include
+ the DNS Zone Suffix Option in their advertisements. If the DNS
+ Zone Suffix changes (similar to Site Renumbering), then it should
+ advertise the Old Zone Suffix with zero Valid Lifetime and New
+ Zone Suffix with proper non-zero Valid Lifetime. In any other
+ case, a router should not send this option twice in a single
+ router advertisement.
+
+ 7.3.2. Processing Router Advertisement Messages
+
+ For each DNS Zone Suffix Option in Router Advertisement,
+
+ a. 6DNAC node stores the Zone Suffix information in its local
+ database. Also, constructs FQDN as per Host Naming Algorithm.
+
+ b. If the node has not configured FQDN yet,
+
+ 1. If the node is going to perform DAD for either Site local or
+ Global Address, then it should include FQDN option to perform
+ Duplicate FQDN Detection in parallel with DAD.
+
+ 2. If the node has already got either Site local or Global
+ address, then it should send out NS with FQDN option and
+ unspecified target address to perform Duplicate FQDN
+ Detection.
+
+ c. If the node has already configured FQDN, and if the
+ advertisement carries two DNS Zone Suffix Options,
+ First DNS Zone Suffix should match with the configured FQDN
+ Suffix and its Valid Lifetime must be zero. Second DNS Zone
+
+
+
+Park & Madanapalli Expires October 2003 [Page 22]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ Suffix should have non-zero Valid Lifetime. In this case, the
+ node constructs new FQDN based on the new DNS Zone Suffix (from
+ second DNS Zone Suffix option), and perform Duplicate FQDN
+ Detection with unspecified target address. Also, it should
+ overwrite the old FQDN with the newly constructed FQDN.
+
+
+ 7.3.3. FQDN Lifetime expiry
+
+ 6DNAC Server:
+ It should delete the FQDN cache entry and should de-register from
+ the DNS Server.
+
+ 6DNAC Client:
+ It should send update to 6DNAC Server by restarting the Duplicate
+ FQDN Detection.
+
+ 7.3.4. Host Naming Algorithm
+
+ A node constructs FQDN by combining DNS Zone Suffix and the hostname
+ as depicted in the following diagram.
+
+ +------------------+----------------------------------+
+ | Host Name | Advertised Suffix |
+ +------------------+----------------------------------+
+
+ <Figure 13: Fully Qualified Domain Name format>
+
+ A node can choose Host Name using any of the following methods:
+
+ a. String form of random number generated from the Interface
+ Identifier.
+
+ b. List of configured Host Names provided by the administrator.
+
+
+ The number of retries must be specified in this algorithm in
+ case of domain name duplication.
+
+
+ 7.4. Duplicate Domain Name Detection
+
+ The procedure for detecting duplicated FQDNs uses Neighbor
+ Solicitation and Advertisement messages as described below.
+
+ If a duplicate FQDN is detected during the procedure, the
+ FQDN cannot be assigned to the node.
+
+ An FQDN on which the DFQDND Procedure is applied is said
+ to be tentative until the procedure has completed successfully.
+ A tentative FQDN is not considered "assigned to the node" in the
+ traditional sense. That is, the node must accept Neighbor
+ Advertisement message containing the tentative FQDN in the FQDN
+ Option.
+
+
+Park & Madanapalli Expires October 2003 [Page 23]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ It should also be noted that DFQDN must be performed prior to
+ registering with DNS Server to prevent multiple nodes from using
+ the same FQDN simultaneously. All the Duplicate Address Detection
+ Neighbor Solicitation messages must carry Source Link Layer Address
+ Option as specified in NDP [2461].
+
+ The detection of duplicate FQDN can be achieved through one of the
+ following three types of procedures.
+
+ 1. DAD with All Nodes Multicast Address
+ 2. DAD with Router Alert Option for 6DNAC.
+ 3. Explicit Detection of Duplicate Domain Name
+
+ Even though three solutions are listed, authors prefer only one
+ procedure to be followed in future based on further analysis and
+ comments received from others.
+
+ 7.4.1. DAD with All Nodes Multicast Address
+
+ 7.4.1.1. Sending Neighbor Solicitation Messages
+
+ 6DNAC Client sends Neighbor Solicitation Messages as part
+ of Duplicate Address Detection SLAAC [2462] with the following
+ extra information and modifications:
+
+ a. Include FQDN Option in the DAD Neighbor Solicitation Message
+ b. Destination Address is set to All Nodes Multicast Address
+
+ There may be a case where DAD has succeeded but DFQDND is in Retry
+ Mode. In such case, the Neighbor Solicitation must carry unspecified
+ address in the ICMP target address field and new domain name in FQDN
+ option to re-try the registration of the domain name.
+
+ 7.4.1.2. Processing Neighbor Solicitation Messages
+
+ 6DNAC Clients must ignore the FQDN option found in any of the
+ neighbor solicitation messages.
+
+ 6DNAC Server processes FQDN Option found in the Duplicate Address
+ Detection Neighbor Solicitation Messages as described below:
+
+ Lookup FQDN Cache for the domain name in FQDN Option.
+
+ If the entry exists and
+ i. Link Layer Address matches with SLLA option, this is the case,
+ where node has changed its IPv6 address or updating the valid
+ life time. 6DNAC Server updates its cache and also updates DNS
+ Server using DDNS-UPDATE. If there is no change in IPv6 address
+ or life time then no updates are sent to the DNS server.
+
+ ii. Link Layer Address differs with SLLA option, defend the duplicate
+ FQDN Detection by sending Neighbor Advertisement Message as
+ described in $7.4.1.3$.
+
+
+
+Park & Madanapalli Expires October 2003 [Page 24]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ else,
+ Lookup FQDN Cache for the Link Layer Address in SLLA Option.
+
+ If the entry exists, update the FQDN Cache and update DNS Server
+ using DDNS-UPDATE. This is the case, where node has changed its
+ domain name (similar to Site Re-numbering).
+
+ If then entry does not exists, then it means that this is the new
+ registration. It must create a cache entry and start Registration
+
+ timer with RegistrationWaitTime. At the expiry of the Registration
+ timer, it should update DNS Server with DDNS-UPDATE.
+
+ 7.4.1.3. Sending Neighbor Advertisement Messages
+
+ 6DNAC Server sends Neighbor Advertisement Messages as part
+ of Duplicate Address Detection SLAAC [2462] with the FQDN Option
+ in Neighbor Advertisement message to defend duplicate FQDN
+ detection.
+
+ There may be the case where defending of duplicate address detection
+ is not required but defending of FQDN is required. In such instance,
+ the defending Neighbor Advertisement must carry FQDN and unspecified
+ address in the ICMP target address field.
+
+ 7.4.1.4. Processing Neighbor Advertisement Messages
+
+ 6DNAC Server must ignore the any FQDN option found any of
+ the neighbor advertisement messages. If the Neighbor Advertisement
+ is a DAD defending, then it must delete its FQDN Cache entry created
+ on the reception of DAD Neighbor Solicitation message.
+
+ When 6DNAC Clients gets the duplicate address detection neighbor
+ advertisement messages with FQDN option set it means that its
+ duplicate FQDN detection failed and enters Retry Mode.
+
+ 7.4.1.5. Pros and Cons
+
+ The advantage of this procedure is that it does not need any
+ extension header options to be included. The disadvantage of this
+ procedure is that, it needs change in the existing DAD procedure.
+ The change is only that the DAD neighbor solicitations are to be
+ addressed to all nodes multicast address instead of solicited
+ node multicast address. The another disadvantage is that, it needs
+ the existence of Duplicate Address Detection Procedure to
+ perform duplicate FQDN detection.
+
+ 7.4.2. DAD with Router Alert Option for 6DNAC
+
+ 7.4.2.1. Sending Neighbor Solicitation Messages
+
+ 6DNAC Client sends Neighbor Solicitation Messages as part
+ of Duplicate Address Detection SLAAC [2462] with the following
+ extra information:
+
+
+Park & Madanapalli Expires October 2003 [Page 25]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ a. Include Hop-by-Hop extension Header with Router Alert Option
+ for 6DNAC as described in IPv6 Router Alert Option[2711].
+
+ b. Include FQDN Option in the DAD Neighbor Solicitation Message
+
+ 7.4.2.2. Processing Neighbor Solicitation Messages
+
+ This is same as described in $7.4.1.2$.
+
+ 7.4.2.3. Sending Neighbor Advertisement Messages
+
+ This is same as described in $7.4.1.3$.
+
+ 7.4.2.4. Processing Neighbor Advertisement Messages
+
+ This is same as described in $7.4.1.4$.
+
+ 7.4.2.5. Pros and Cons
+
+ The advantage of this procedure is that it does not disturb
+ the existing implementation and their way of processing the
+ packets. The disadvantage is that, it needs the existence
+ of Duplicate Address Detection Procedure to perform duplicate
+ FQDN detection. Another disadvantage is that this procedure
+ requires 6DNAC Server functionality to be implemented on Router.
+ However, in this case 6DNAC Server can serve multiple links.
+
+ 7.4.3. Explicit Detection of Duplicate Domain Name
+
+ In this procedure Duplicate FQDN Detection starts after completion
+ of successful Site local or Global Address configuration.
+
+ 7.4.3.1. Sending Neighbor Solicitation Messages
+
+ 6DNAC Client sends Neighbor Solicitation Messages as part
+ of Duplicate FQDN Detection with the following information:
+
+ a. Include FQDN Option in the Neighbor Solicitation Message
+
+ b. Destination Address is set to All Nodes Multicast Address
+ or uses Router Alert Option for 6DNAC, when 6DNAC Server is
+ implemented on router.
+
+ c. Target Address is set to Unspecified Address
+
+ d. Other fields are set as per DAD SLAAC [2462].
+
+ 7.4.3.2. Processing Neighbor Solicitation Messages
+
+ This is same as described in $7.4.1.2$.
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 26]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ 7.4.3.3. Sending Neighbor Advertisement Messages
+
+ This is same as described in $7.4.1.3$.
+
+ 7.4.3.4. Processing Neighbor Advertisement Messages
+
+ This is same as described in $7.4.1.4$.
+
+ 7.4.3.5. Pros and Cons
+
+ The advantage of this procedure is that it does not need the
+ existing duplicate address detection procedure. This is introduced
+ as the DAD procedure is found to be redundant in when IPv6 addresses
+ are constructed from the interface ID [DIID].
+
+ Note that, if 6DNAC Clients know the address of 6DNAC Server then
+ they can directly send DFQDND-NS to 6DNAC Server.
+
+ 7.4.4. Retry Mode for Re-registering Domain Name
+
+ In retry mode, nodes construct new FQDN as per Host Naming Algorithm.
+ Then they restart Duplicate FQDN Detection as described in $7.4.3$.
+
+
+ 7.5. Domain Name Registration
+
+ 6DNAC Server must be an authenticated to update the DNS Server.
+ 6DNAC Server must also be configured with the DNS Server
+ information.
+
+ 6DNAC Server detects the DNS information (IPv6 Address and
+ corresponding FQDN) from DAD/DFQDND messages and caches the
+ information. It also have an associated Registration Timer with
+ RegistrationWaitTime to wait for the successful completion of
+ DFQDND and update DNS Server using existing protocol DDNS UPDATE
+ [2136].
+
+
+ 8. Security Consideration
+
+ If someone wants to hijack correct Domain Name registration, they
+ could send a NS message with incorrect or same Domain Name to the
+ 6DNAC server repeatedly and server would start the Domain Name
+ registration through above mechanism, which is a security hole.
+ As described in [2461], a host can check validity of NDP messages.
+ If the NDP message include an IP Authentication Header, the message
+ authenticates correctly. For DNS UPDATE processing, secure DNS
+ Dynamic Update is described in [3007].
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 27]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ 9. IANA Consideration
+
+ Values in the Router Alert Option are registered and maintained by
+ IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is
+ required to assign the Type values for DNS Zone Suffix Information
+ option and FADN option.
+
+
+ 10. Acknowledgement
+
+ Special thanks are due to Badrinarayana N.S. and Christian Huitema for
+ many helpful suggestions and revisions.
+
+
+ 11. Intellectual Property
+
+ The following notice is copied from RFC 2026 [Bradner, 1996],
+ Section 10.4, and describes the position of the IETF concerning
+ intellectual property claims made against this document.
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use other technology described in
+
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication 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 Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+ 12. Copyright
+
+ The following copyright notice is copied from RFC 2026 [Bradner,
+ 1996], Section 10.4, and describes the applicable copyright for this
+ document.
+
+ Copyright (C) The Internet Society July 12, 2001. All Rights
+ Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+
+Park & Madanapalli Expires October 2003 [Page 28]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph
+ are included on all such copies and derivative works. However, this
+
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+
+ 13. References
+
+ [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 2373, July 1998.
+
+ [2460] Deering, S. abd R. Hinden, "Internet Protocol,
+ Version 6 (IPv6) Specification", RFC 2460,
+ December 1998.
+
+ [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
+ Discovery for IP version 6(IPv6)", RFC 2461, December
+ 1998.
+
+ [2462] S. Thomson and Narten T, "IPv6 Stateless Address Auto-
+ Configuration", RFC 2462, December 1998.
+
+ [2711] C. Patridge and A.Jackson, "IPv6 Router Alert Option",
+ RFC 2711, October 1999.
+
+ [1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND
+ FACILITIES", RFC 1034, November 1987.
+
+ [1035] P. Mockapetris, "Domain Names - Implementation and
+ Specification" RFC 1035, November 1987.
+
+ [2136] P. Vixie et al., "Dynamic Updates in the Domain Name
+ System (DNS UPDATE)", RFC2136, April 1997.
+
+ [3007] B. Wellington, "Secure Domain Name System (DNS) Dynamic
+ Update", RFC 3007, November 2000.
+
+
+
+Park & Madanapalli Expires October 2003 [Page 29]
+
+INTERNET-DRAFT IPv6 Extensions for DNS Plug and Play April 2003
+
+
+ [DIID] yokohama-dad-vs-diid.pdf
+ at http://playground.sun.com/ipng/presentations/July2002/
+
+ [DNSISSUES] Durand, A., "IPv6 DNS transition issues", draft-ietf-
+ dnsop-ipv6-dns-issues-00.txt, work in progress.
+
+ [PREFIX] S. Miyakawa, R. Droms, "Requirements for IPv6 prefix
+ delegation", draft-ietf-ipv6-prefix-delegation-
+ requirement-01.txt, work in progress.
+
+ [Autoreg] H. Kitamura, "Domain Name Auto-Registration for
+ Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name-
+ auto-reg-00.txt, work in progress.
+
+ [NIQ] Matt Crawford, "IPv6 Node Information Queries", <draft-
+ ietf-ipngwg-icmp-name-lookups-09.txt>, work in progress.
+
+
+ 14. Author's Addresses
+
+ Soohong Daniel Park
+ Mobile Platform Laboratory, SAMSUNG Electronics, KOREA
+ Phone: +82-31-200-3728
+ Email:soohong.park@samsung.com
+
+ Syam Madanapalli
+ Network Systems Division, SAMSUNG India Software Operations, INDIA
+ Phone: +91-80-5550555
+ Email:syam@samsung.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Park & Madanapalli Expires October 2003 [Page 30]
diff --git a/doc/draft/update b/doc/draft/update
new file mode 100644
index 0000000..6ac2090
--- /dev/null
+++ b/doc/draft/update
@@ -0,0 +1,46 @@
+#!/bin/sh
+commit=
+for i
+do
+ z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
+ if test -n "$z"
+ then
+ i="$z"
+ fi
+ if test -f "$i"
+ then
+ continue
+ fi
+ pat=`echo "$i" | sed 's/...txt/??.txt/'`
+ old=`echo $pat 2> /dev/null`
+ if test "X$old" != "X$pat"
+ then
+ newer=0
+ for j in $old
+ do
+ if test $j ">" $i
+ then
+ newer=1
+ fi
+ done
+ if test $newer = 1
+ then
+ continue;
+ fi
+ fi
+ if fetch "http://www.ietf.org/internet-drafts/$i"
+ then
+ cvs add "$i"
+ if test "X$old" != "X$pat"
+ then
+ rm $old
+ cvs delete $old
+ commit="$commit $old"
+ fi
+ commit="$commit $i"
+ fi
+done
+if test -n "$commit"
+then
+ cvs commit -m "new draft" $commit
+fi
--
cgit v1.1