+++ /dev/null
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
+++ /dev/null
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-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-----------------------
-
+++ /dev/null
-DNS Extensions working group V.Dolmatov, Ed.
-Internet-Draft Cryptocom Ltd.
-Intended status: Standards Track April 8, 2009
-Expires: December 31, 2009
-
-
- Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
- for DNSSEC
- draft-dolmatov-dnsext-dnssec-gost-00
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on 31 December 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-Abstract
-
- This document describes how to produce GOST signature and hash algorithms
- DNSKEY and RRSIG resource records for use in the Domain Name System
- Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035).
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
- 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . .
- 2.1. Using a public key with existing cryptographic libraries. .
- 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . .
- 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . .
- 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . .
- 5. NSEC3 Resource Records . . . . . . . . . . . . . . . . . . . .
- 6. Deployment Considerations . . . . . . . . . . . . . . . . . . .
- 6.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . .
- 6.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . .
- 6.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . .
- 7. Implementation Considerations . . . . . . . . . . . . . . . . .
- 7.1. Support for GOST signatures . . . . . . . . . . . . . . . .
- 7.2. Support for NSEC3 Denial of Existence . . . . . . . . . . .
- 7.2.1. NSEC3 in Authoritative servers . . . . . . . . . . . .
- 7.2.2. NSEC3 in Validators . . . . . . . . . . . . . . . . . .
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . .
- 10.1. Normative References . . . . . . . . . . . . . . . . . . .
- 10.2. Informative References . . . . . . . . . . . . . . . . . .
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical distributed
- database for Internet Naming. The DNS has been extended to use
- cryptographic keys and digital signatures for the verification of the
- authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034
- [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
- Extensions, called DNSSEC.
-
- RFC 4034 describes how to store DNSKEY and RRSIG resource records,
- and specifies a list of cryptographic algorithms to use. This
- document extends that list with the signature and hash algorithms
- GOST [GOST3410, GOST3411],
- and specifies how to store DNSKEY data and how to produce
- RRSIG resource records with these hash algorithms.
-
- Familiarity with DNSSEC and GOST signature and hash
- algorithms is assumed in this document.
-
- The term "GOST" is not officially defined, but is usually used to
- refer to the collection of the Russian cryptographic algorithms
- GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. Since GOST 28147-89
- is not used in DNSSEC, GOST will only refer to GOST R 34.10-2001
- (signatire algorithm) and GOST R 34.11-94 (hash algorithm) in this
- document.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-2. DNSKEY Resource Records
-
- The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
- GOST R 34.10-2001 public keys are stored with the algorithm number {TBA1}.
-
- The public key parameters are those identified by
- id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357].
- The digest parameters for signature are those identified by
- id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
- The wire format of the public key is compatible with RFC 4491 [RFC4491]:
-
- According to [GOSTR341001], a public key is a point on the elliptic
- curve Q = (x,y).
-
- The wire representation of a public key MUST contain 64 octets, where the
- first 32 octets contain the little-endian representation of x and the
- second 32 octets contain the little-endian representation of y. This
- corresponds to the binary representation of (<y>256||<x>256) from
- [GOSTR341001], ch. 5.3.
-
-2.1. Using a public key with existing cryptographic libraries
-
- Existing GOST-aware cryptographic libraries at time of this document
- writing are capable to read GOST public keys via generic X509 API if the
- key is encoded according to RFC 4491 [RFC4491], section 2.3.2.
-
- To make this encoding from the wire format of a GOST public key, prepend
- a key data with the following 37-byte sequence:
-
- 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 0x12
- 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a 0x85 0x03
- 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-
-2.2. GOST DNSKEY RR Example
-
- The following DNSKEY RR stores a DNS zone key for example.com
-
- example.com. 86400 IN DNSKEY 256 3 {TBA1} ( RamuUwTG1r4RUqsgXu/xF6B+Y
- tJLzZEykiZ4C2Fa1gV1pI/8GA
- el2Wm69Cz5h1T9eYAQKFAGwzW
- m4Lke0E26aw== )
-
-3. RRSIG Resource Records
-
- The value of the signature field in the RRSIG RR follows the RFC 4490
- [RFC4490] and is calculated as follows. The values for the RDATA fields
- that precede the signature data are specified in RFC 4034 [RFC4034].
-
- hash = GOSTR3411(data)
-
- where "data" is the wire format data of the resource record set that is
- signed, as specified in RFC 4034 [RFC4034]. Hash MUST be calculated with
- GOST R 34.11-94 parameters identified by
- id-GostR3411-94-CryptoProParamSet [RFC4357].
-
- Signature is calculated from the hash according to the GOST R 34.10-2001
- standard and its wire format is compatible with RFC 4490 [RFC4490].
- Quoting RFC 4490:
-
- "The signature algorithm GOST R 34.10-2001 generates a digital
- signature in the form of two 256-bit numbers, r and s. Its octet
- string representation consists of 64 octets, where the first 32
- octets contain the big-endian representation of s and the second 32
- octets contain the big-endian representation of r."
-
-4. DS Resource Records
-
- GOST R 34.11-94 digest algorithm is denoted in DS RR by the digest type
- {TBA2}. The wire format of a digest value is compatible with RFC 4490
- [RFC4490]. Quoting RFC 4490:
-
- "A 32-byte digest in little-endian representation."
-
- The digest MUST always be calculated with GOST R 34.11-94 parameters
- identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-5. NSEC3 Resource Records
-
- GOST R 34.11-94 digest algorithm is denoted in NSEC3 RR by the digest type
- {TBA2}. The wire format of a digest value is compatible with RFC 4490
- [RFC4490]. Quoting RFC 4490:
-
- "A 32-byte digest in little-endian representation."
-
- The digest MUST always be calculated with GOST R 34.11-94 parameters
- identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-6. Deployment Considerations
-
-6.1. Key Sizes
-
- According to RFC4357 [RFC4357] key size of GOST public keys MUST
- be 512 bits.
-
-6.2. Signature Sizes
-
- According to GOST signature algorithm [GOST3410] size of GOST signature
- is 512 bit.
-
-6.3. Digest Sizes
-
- According to GOST R 34.11-94 [GOST3411] size of GOST digest is 256 bit.
-
-7. Implementation Considerations
-
-7.1. Support for GOST signatures
-
- DNSSEC aware implementations SHOULD be able to support RRSIG and
- DNSKEY resource records created with the GOST algorithms as
- defined in this document.
-
-7.2. Support for NSEC3 Denial of Existence
-
- RFC5155 [RFC5155] defines new algorithm identifiers for existing
- signing algorithms, to indicate that zones signed with these
- algorithm identifiers use NSEC3 instead of NSEC records to provide
- denial of existence. That mechanism was chosen to protect
- implementations predating RFC5155 from encountering resource records
- they could not know about. This document does not define such
- algorithm aliases, and support for NSEC3 denial of existence is
- implicitly signaled with support for one of the algorithms defined in
- this document.
-
-7.2.1. NSEC3 in Authoritative servers
-
- An authoritative server that does not implement NSEC3 MAY still serve
- zones that use GOST with NSEC denial of existence.
-
-7.2.2. NSEC3 in Validators
-
- A DNSSEC validator that implements GOST MUST be able to handle
- both NSEC and NSEC3 [RFC5155] negative answers. If this is not the
- case, the validator MUST treat a zone signed with GOST
- as signed with an unknown algorithm, and thus as insecure.
-
-
-8. IANA Considerations
-
- This document updates the IANA registry "DNS SECURITY ALGORITHM
- NUMBERS -- per [RFC4035] "
- (http://www.iana.org/assignments/dns-sec-alg-numbers). The following
- entries are added to the registry:
- Zone Trans.
- Value Algorithm Mnemonic Signing Sec. References Status
- {TBA1} GOST R 34.10-2001 GOST Y * (this memo) OPTIONAL
-
- This document updates the RFC 4034 [RFC4034] Digest Types assignment
- (RFC 4034, section A.2):
-
- Value Algorithm Status
- {TBA2} GOST R 34.11-94 OPTIONAL
-
-9. Acknowledgments
-
- This document is a minor extension to RFC 4034 [RFC4034]. Also, we
- try to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509]
- and RFC 4357 [RFC4357] for consistency. The authors of and
- contributors to these documents are gratefully acknowledged for
- their hard work.
-
- The following people provided additional feedback and text: Dmitry
- Burkov, Jaap Akkerhuis, Jelte Jansen and Wouter Wijngaards.
-
-
-10. References
-
-10.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
- Name System (DNS)", RFC 3110, May 2001.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [GOST3410] "Information technology. Cryptographic data security.
- Signature and verification processes of [electronic]
- digital signature.", GOST R 34.10-2001, Gosudarstvennyi
- Standard of Russian Federation, Government Committee of
- the Russia for Standards, 2001. (In Russian)
-
- [GOST3411] "Information technology. Cryptographic Data Security.
- Hashing function.", GOST R 34.11-94, Gosudarstvennyi
- Standard of Russian Federation, Government Committee of
- the Russia for Standards, 1994. (In Russian)
-
- [RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional
- Cryptographic Algorithms for Use with GOST 28147-89,
- GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
- Algorithms", RFC 4357, January 2006.
-
- [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89,
- GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001
- Algorithms with Cryptographic Message Syntax (CMS)",
- RFC 4490, May 2006.
-
- [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST
- R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
- Algorithms with the Internet X.509 Public Key
- Infrastructure Certificate and CRL Profile", RFC 4491,
- May 2006.
-
-
-
-10.2. Informative References
-
- [NIST800-57]
- Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
- "Recommendations for Key Management", NIST SP 800-57,
- March 2007.
-
- [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
- Standards (PKCS) #1: RSA Cryptography Specifications
- Version 2.1", RFC 3447, February 2003.
-
- [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-Authors' Addresses
-
-
-Vasily Dolmatov, Ed.
-Cryptocom Ltd.
-Bolotnikovskaya, 23
-Moscow, 117303, Russian Federation
-
-EMail: dol@cryptocom.ru
-
-Artem Chuprina
-Cryptocom Ltd.
-Bolotnikovskaya, 23
-Moscow, 117303, Russian Federation
-
-EMail: ran@cryptocom.ru
-
-Igor Ustinov
-Cryptocom Ltd.
-Bolotnikovskaya, 23
-Moscow, 117303, Russian Federation
-
-EMail: igus@cryptocom.ru
-
- Expires December 31, 2009 [Page ]
-
-
+++ /dev/null
-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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+++ /dev/null
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-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]
-\f
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
- work in progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 15]
-\f
-
-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]
-\f
+++ /dev/null
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-DNSEXT R. Bellis
-Internet-Draft Nominet UK
-Intended status: BCP April 23, 2009
-Expires: October 25, 2009
-
-
- DNS Proxy Implementation Guidelines
- draft-ietf-dnsext-dnsproxy-05
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on October 25, 2009.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-Abstract
-
- This document provides guidelines for the implementation of DNS
- proxies, as found in broadband gateways and other similar network
- devices.
-
-
-
-Bellis Expires October 25, 2009 [Page 1]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
- 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
-
- 3. The Transparency Principle . . . . . . . . . . . . . . . . . . 3
-
- 4. Protocol Conformance . . . . . . . . . . . . . . . . . . . . . 4
- 4.1. Unexpected Flags and Data . . . . . . . . . . . . . . . . 4
- 4.2. Label Compression . . . . . . . . . . . . . . . . . . . . 4
- 4.3. Unknown Resource Record Types . . . . . . . . . . . . . . 5
- 4.4. Packet Size Limits . . . . . . . . . . . . . . . . . . . . 5
- 4.4.1. TCP Transport . . . . . . . . . . . . . . . . . . . . 6
- 4.4.2. Extension Mechanisms for DNS (EDNS0) . . . . . . . . . 6
- 4.4.3. IP Fragmentation . . . . . . . . . . . . . . . . . . . 6
- 4.5. Secret Key Transaction Authentication for DNS (TSIG) . . . 7
-
- 5. DHCP's Interaction with DNS . . . . . . . . . . . . . . . . . 7
- 5.1. Domain Name Server (DHCP Option 6) . . . . . . . . . . . . 8
- 5.2. Domain Name (DHCP Option 15) . . . . . . . . . . . . . . . 8
- 5.3. DHCP Leases . . . . . . . . . . . . . . . . . . . . . . . 8
-
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
- 6.1. Forgery Resilience . . . . . . . . . . . . . . . . . . . . 9
- 6.2. Interface Binding . . . . . . . . . . . . . . . . . . . . 10
- 6.3. Packet Filtering . . . . . . . . . . . . . . . . . . . . . 10
-
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
-
- 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
-
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
-
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis Expires October 25, 2009 [Page 2]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
-1. Introduction
-
- Research has found ([SAC035], [DOTSE]) that many commonly-used
- broadband gateways (and similar devices) contain DNS proxies which
- are incompatible in various ways with current DNS standards.
-
- These proxies are usually simple DNS forwarders, but typically do not
- have any caching capabilities. The proxy serves as a convenient
- default DNS resolver for clients on the LAN, but relies on an
- upstream resolver (e.g. at an ISP) to perform recursive DNS lookups.
-
- Note that to ensure full DNS protocol interoperability it is
- preferred that client stub resolvers should communicate directly with
- full-feature upstream recursive resolvers wherever possible.
-
- That notwithstanding, this document describes the incompatibilities
- that have been discovered and offers guidelines to implementors on
- how to provide better interoperability in those cases where the
- client must use the broadband gateway's DNS proxy.
-
-
-2. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-3. The Transparency Principle
-
- It is not considered practical for a simple DNS proxy to implement
- all current and future DNS features.
-
- There are several reasons why this is the case:
-
- o broadband gateways usually have limited hardware resources
- o firmware upgrade cycles are long, and many users do not routinely
- apply upgrades when they become available
- o no-one knows what those future DNS features will be, nor how they
- might be implemented
- o it would substantially complicate the configuration UI of the
- device
-
- Furthermore some modern DNS protocol extensions (see e.g. EDNS0,
- below) are intended to be used as "hop-by-hop" mechanisms. If the
- DNS proxy is considered to be such a "hop" in the resolution chain,
- then for it to function correctly, it would need to be fully
- compliant with all such mechanisms.
-
-
-
-Bellis Expires October 25, 2009 [Page 3]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
- [SAC035] shows that the more actively a proxy participates in the DNS
- protocol then the more likely it is that it will somehow interfere
- with the flow of messages between the DNS client and the upstream
- recursive resolvers.
-
- The role of the proxy should therefore be no more and no less than to
- receive DNS requests from clients on the LAN side, forward those
- verbatim to one of the known upstream recursive resolvers on the WAN
- side, and ensure that the whole response is returned verbatim to the
- original client.
-
- It is RECOMMENDED that proxies should be as transparent as possible,
- such that any "hop-by-hop" mechanisms or newly introduced protocol
- extensions operate as if the proxy were not there.
-
- Except when required to enforce an active security or network policy
- (such as maintaining a pre-authentication "walled garden"), end-users
- SHOULD be able to send their DNS queries to specified upstream
- resolvers, thereby bypassing the proxy altogether. In this case, the
- gateway SHOULD NOT modify the DNS request or response packets in any
- way.
-
-
-4. Protocol Conformance
-
-4.1. Unexpected Flags and Data
-
- The Transparency Principle above, when combined with Postel's
- Robustness Principle [RFC0793], suggests that DNS proxies should not
- arbitrarily reject or otherwise drop requests or responses based on
- perceived non-compliance with standards.
-
- For example, some proxies have been observed to drop any packet
- containing either the "Authentic Data" (AD) or "Checking Disabled"
- (CD) bits from DNSSEC [RFC4035]. This may be because [RFC1035]
- originally specified that these unused "Z" flag bits "MUST" be zero.
- However these flag bits were always intended to be reserved for
- future use, so refusing to proxy any packet containing these flags
- (now that uses for those flags have indeed been defined) is not
- appropriate.
-
- Therefore it is RECOMMENDED that proxies SHOULD ignore any unknown
- DNS flags and proxy those packets as usual.
-
-4.2. Label Compression
-
- Compression of labels as per Section 4.1.4 of [RFC1035] is optional.
-
-
-
-
-Bellis Expires October 25, 2009 [Page 4]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
- Proxies MUST forward packets regardless of the presence or absence of
- compressed labels therein.
-
-4.3. Unknown Resource Record Types
-
- [RFC3597] requires that resolvers MUST handle Resource Records (RRs)
- of unknown type transparently.
-
- All requests and responses MUST be proxied regardless of the values
- of the QTYPE and QCLASS fields.
-
- Similarly all responses MUST be proxied regardless of the values of
- the TYPE and CLASS fields of any Resource Record therein.
-
-4.4. Packet Size Limits
-
- [RFC1035] specifies that the maximum size of the DNS payload in a UDP
- packet is 512 octets. Where the required portions of a response
- would not fit inside that limit the DNS server MUST set the
- "TrunCation" (TC) bit in the DNS response header to indicate that
- truncation has occurred. There are however two standard mechanisms
- (described in Section 4.4.1 and Section 4.4.2) for transporting
- responses larger than 512 octets.
-
- Many proxies have been observed to truncate all responses at 512
- octets, and others at a packet size related to the WAN MTU, in either
- case doing so without correctly setting the TC bit.
-
- Other proxies have been observed to remove the TC bit in server
- responses which correctly had the TC bit set by the server.
-
- If a DNS response is truncated but the TC bit is not set then client
- failures may result. In particular a naive DNS client library might
- suffer crashes due to reading beyond the end of the data actually
- received.
-
- Since UDP packets larger than 512 octets are now expected in normal
- operation, proxies SHOULD NOT truncate UDP packets that exceed that
- size. See Section 4.4.3 for recommendations for packet sizes
- exceeding the WAN MTU.
-
- If a proxy must unilaterally truncate a response then the proxy MUST
- set the TC bit. Similarly, proxies MUST NOT remove the TC bit from
- responses.
-
-
-
-
-
-
-
-Bellis Expires October 25, 2009 [Page 5]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
-4.4.1. TCP Transport
-
- Should a UDP query fail because of truncation, the standard fail-over
- mechanism is to retry the query using TCP, as described in section
- 6.1.3.2 of [RFC1123].
-
- DNS proxies SHOULD therefore be prepared to receive and forward
- queries over TCP.
-
- Note that it is unlikely that a client would send a request over TCP
- unless it had already received a truncated UDP response. Some
- "smart" proxies have been observed to first forward any request
- received over TCP to an upstream resolver over UDP, only for the
- response to be truncated, causing the proxy to retry over TCP. Such
- behaviour increases network traffic and causes delay in DNS
- resolution since the initial UDP request is doomed to fail.
-
- Therefore whenever a proxy receives a request over TCP, the proxy
- SHOULD forward the query over TCP and SHOULD NOT attempt the same
- query over UDP first.
-
-4.4.2. Extension Mechanisms for DNS (EDNS0)
-
- The Extension Mechanism for DNS [RFC2671] was introduced to allow the
- transport of larger DNS packets over UDP and also to allow for
- additional request and response flags.
-
- A client may send an OPT Resource Record (OPT RR) in the Additional
- Section of a request to indicate that it supports a specific receive
- buffer size. The OPT RR also includes the "DNSSEC OK" (DO) flag used
- by DNSSEC to indicate that DNSSEC-related RRs should be returned to
- the client.
-
- However some proxies have been observed to either reject (with a
- FORMERR response code) or black-hole any packet containing an OPT RR.
- As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets.
-
-4.4.3. IP Fragmentation
-
- Support for UDP packet sizes exceeding the WAN MTU depends on the
- gateway's algorithm for handling fragmented IP packets. Several
- methods are possible:
-
- 1. fragments are dropped
- 2. fragments are forwarded individually as they're received
- 3. complete packets are reassembled on the gateway, and then re-
- fragmented (if necessary) as they're forwarded to the client
-
-
-
-
-Bellis Expires October 25, 2009 [Page 6]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
- Method 1 above will cause compatibility problems with EDNS0 unless
- the DNS client is configured to advertise an EDNS0 buffer size
- limited to the WAN MTU less the size of the IP header. Note that RFC
- 2671 does recommend that the path MTU should be taken into account
- when using EDNS0.
-
- Also, whilst the EDNS0 specification allows for a buffer size of up
- to 65535 octets, most common DNS server implementations do not
- support a buffer size above 4096 octets.
-
- Therefore (irrespective of which of the methods above is in use)
- proxies SHOULD be capable of forwarding UDP packets up to a payload
- size of at least 4096 octets.
-
- NB: in theory IP fragmentation may also occur if the LAN MTU is
- smaller than the WAN MTU, although the author has not observed such a
- configuration in use on any residential broadband service.
-
-4.5. Secret Key Transaction Authentication for DNS (TSIG)
-
- [RFC2845] defines TSIG, which is a mechanism for authenticating DNS
- requests and responses at the packet level.
-
- Any modifications made to the DNS portions of a TSIG-signed query or
- response packet (with the exception of the Query ID) will cause a
- TSIG authentication failure.
-
- DNS proxies MUST implement Section 4.7 of [RFC2845] and either
- forward packets unchanged (as recommended above) or fully implement
- TSIG.
-
- As per Section 4.3, DNS proxies MUST be capable of proxying packets
- containing TKEY [RFC2930] Resource Records.
-
- NB: any DNS proxy (such as those commonly found in WiFi hotspot
- "walled gardens") which transparently intercepts all DNS queries, and
- which returns unsigned responses to signed queries, will also cause
- TSIG authentication failures.
-
-
-5. DHCP's Interaction with DNS
-
- Whilst this document is primarily about DNS proxies, most consumers
- rely on DHCP [RFC2131] to obtain network configuration settings.
- Such settings include the client machine's IP address, subnet mask
- and default gateway, but also include DNS related settings.
-
- It is therefore appropriate to examine how DHCP affects client DNS
-
-
-
-Bellis Expires October 25, 2009 [Page 7]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
- configuration.
-
-5.1. Domain Name Server (DHCP Option 6)
-
- Most gateways default to supplying their own IP address in the DHCP
- "Domain Name Server" option [RFC2132]. The net result is that
- without explicit re-configuration many DNS clients will by default
- send queries to the gateway's DNS proxy. This is understandable
- behaviour given that the correct upstream settings are not usually
- known at boot time.
-
- Most gateways learn their own DNS settings via values supplied by an
- ISP via DHCP or PPP over the WAN interface. However whilst many
- gateways do allow the device administrator to override those values,
- some gateways only use those supplied values to affect the proxy's
- own forwarding function, and do not offer these values via DHCP.
-
- When using such a device the only way to avoid using the DNS proxy is
- to hard-code the required values in the client operating system.
- This may be acceptable for a desktop system but it is inappropriate
- for mobile devices which are regularly used on many different
- networks.
-
- As per Section 3, end-users SHOULD be able to send their DNS queries
- directly to specified upstream resolvers, ideally without hard-coding
- those settings in their stub resolver.
-
- It is therefore RECOMMENDED that gateways SHOULD support device
- administrator configuration of values for the "Domain Name Server"
- DHCP option.
-
-5.2. Domain Name (DHCP Option 15)
-
- A significant amount of traffic to the DNS Root Name Servers is for
- invalid top-level domain names, and some of that traffic can be
- attributed to particular equipment vendors whose firmware defaults
- this DHCP option to specific values.
-
- Since no standard exists for a "local" scoped domain name suffix it
- is RECOMMENDED that the default value for this option SHOULD be
- empty, and that this option MUST NOT be sent to clients when no value
- is configured.
-
-5.3. DHCP Leases
-
- It is noted that some DHCP servers in broadband gateways by default
- offer their own IP address for the "Domain Name Server" option (as
- described above) but then automatically start offering the upstream
-
-
-
-Bellis Expires October 25, 2009 [Page 8]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
- servers' addresses once they've been learnt over the WAN interface.
-
- In general this behaviour is highly desirable, but the effect for the
- end-user is that the settings used depend on whether the DHCP lease
- was obtained before or after the WAN link was established.
-
- If the DHCP lease is obtained whilst the WAN link is down then the
- DHCP client (and hence the DNS client) will not receive the correct
- values until the DHCP lease is renewed.
-
- Whilst no specific recommendations are given here, vendors may wish
- to give consideration to the length of DHCP leases, and whether some
- mechanism for forcing a DHCP lease renewal might be appropriate.
-
- Another possibility is that the learnt upstream values might be
- persisted in non-volatile memory such that on reboot the same values
- can be automatically offered via DHCP. However this does run the
- risk that incorrect values are initially offered if the device is
- moved or connected to another ISP.
-
- Alternatively, the DHCP server might only issue very short (i.e. 60
- second) leases while the WAN link is down, only reverting to more
- typical lease lengths once the WAN link is up and the upstream DNS
- servers are known. Indeed with such a configuration it may be
- possible to avoid the need to implement a DNS proxy function in the
- broadband gateway at all.
-
-
-6. Security Considerations
-
- This document introduces no new protocols. However there are some
- security related recommendations for vendors that are listed here.
-
-6.1. Forgery Resilience
-
- Whilst DNS proxies are not usually full-feature resolvers they
- nevertheless share some characteristics with them.
-
- Notwithstanding the recommendations above about transparency many DNS
- proxies are observed to pick a new Query ID for outbound requests to
- ensure that responses are directed to the correct client.
-
- NB: Changing the Query ID is acceptable and compatible with proxying
- TSIG-signed packets since the TSIG signature calculation is based on
- the original message ID which is carried in the TSIG RR.
-
- It has been standard guidance for many years that each DNS query
- should use a randomly generated Query ID. However many proxies have
-
-
-
-Bellis Expires October 25, 2009 [Page 9]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
- been observed picking sequential Query IDs for successive requests.
-
- It is strongly RECOMMENDED that DNS proxies follow the relevant
- recommendations in [RFC5452], particularly those in Section 9.2
- relating to randomisation of Query IDs and source ports. This also
- applies to source port selection within any NAT function.
-
- If a DNS proxy is running on a broadband gateway with NAT that is
- compliant with [RFC4787] then it SHOULD also follow the
- recommendations in Section 10 of [RFC5452] concerning how long DNS
- state is kept.
-
-6.2. Interface Binding
-
- Some gateways have been observed to have their DNS proxy listening on
- both internal (LAN) and external (WAN) interfaces. In this
- configuration it is possible for the proxy to be used to mount
- reflector attacks as described in [RFC5358].
-
- The DNS proxy in a gateway SHOULD NOT by default be accessible from
- the WAN interfaces of the device.
-
-6.3. Packet Filtering
-
- The Transparency and Robustness Principles are not entirely
- compatible with the deep packet inspection features of security
- appliances such as firewalls which are intended to protect systems on
- the inside of a network from rogue traffic.
-
- However a clear distinction may be made between traffic that is
- intrinsically malformed and that which merely contains unexpected
- data.
-
- Examples of malformed packets which MAY be dropped include:
-
- o invalid compression pointers (i.e. those that point outside of the
- current packet, or which might cause a parsing loop).
- o incorrect counts for the Question, Answer, Authority and
- Additional Sections (although care should be taken where
- truncation is a possibility).
-
- Since dropped packets will cause the client to repeatedly retransmit
- the original request, it is RECOMMENDED that proxies SHOULD instead
- return a suitable DNS error response to the client (i.e. SERVFAIL)
- instead of dropping the packet completely.
-
-
-
-
-
-
-Bellis Expires October 25, 2009 [Page 10]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
-7. IANA Considerations
-
- This document requests no IANA actions.
-
-
-8. Change Log
-
- NB: to be removed by the RFC Editor before publication.
-
- draft-ietf-dnsproxy-05
- Removed specific reference to 28 byte IP headers (from Mark
- Andrews)
-
- draft-ietf-dnsproxy-04 - post WGLC
- Introduction expanded
- Section 5.2 - changed SHOULD to MUST
- Section 4.5 - changed SHOULD to MUST (Alex Bligh)
- Editorial nits (from Andrew Sullivan, Alfred Hones)
- Clarificaton on end-user vs device administrator (Alan Barrett,
- Paul Selkirk)
-
- draft-ietf-dnsproxy-03
- Editorial nits and mention of LAN MTU (from Alex Bligh)
-
- draft-ietf-dnsproxy-02
- Changed "router" to "gateway" throughout (David Oran)
- Updated forgery resilience reference
- Elaboration on bypassability (from Nicholas W.)
- Elaboration on NAT source port randomisation (from Nicholas W.)
- Mention of using short DHCP leases while the WAN link is down
- (from Ralph Droms)
- Further clarification on permissibility of altering QID when using
- TSIG
-
- draft-ietf-dnsproxy-01
- Strengthened recommendations about truncation (from Shane Kerr)
- New TSIG text (with help from Olafur)
- Additional forgery resilience text (from Olafur)
- Compression support (from Olafur)
- Correction of text re: QID changes and compatibility with TSIG
-
- draft-ietf-dnsproxy-00
- Changed recommended DPI error to SERVFAIL (from Jelte)
- Changed example for invalid compression pointers (from Wouter).
- Note about TSIG implications of changing Query ID (from Wouter).
- Clarified TC-bit text (from Wouter)
-
-
-
-
-
-Bellis Expires October 25, 2009 [Page 11]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
- Extra text about proxy bypass (Nicholas W.)
-
- draft-bellis-dnsproxy-00
- Initial draft
-
-
-9. Acknowledgements
-
- The author would particularly like to acknowledge the assistance of
- Lisa Phifer of Core Competence. In addition the author is grateful
- for the feedback from the members of the DNSEXT Working Group.
-
-
-10. References
-
-10.1. Normative References
-
- [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
- RFC 793, September 1981.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
- and Support", STD 3, RFC 1123, October 1989.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
- RFC 2131, March 1997.
-
- [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 2132, March 1997.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
- RFC 2671, August 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B.
- Wellington, "Secret Key Transaction Authentication for DNS
- (TSIG)", RFC 2845, May 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
- (RR) Types", RFC 3597, September 2003.
-
-
-
-
-Bellis Expires October 25, 2009 [Page 12]
-\f
-Internet-Draft DNS Proxy Implementation Guidelines April 2009
-
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
- (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
- RFC 4787, January 2007.
-
- [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
- Nameservers in Reflector Attacks", BCP 140, RFC 5358,
- October 2008.
-
- [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
- Resilient against Forged Answers", RFC 5452, January 2009.
-
-10.2. Informative References
-
- [DOTSE] Ahlund and Wallstrom, "DNSSEC Tests of Consumer Broadband
- Routers", February 2008,
- <http://www.iis.se/docs/Routertester_en.pdf>.
-
- [SAC035] Bellis, R. and L. Phifer, "Test Report: DNSSEC Impact on
- Broadband Routers and Firewalls", September 2008,
- <http://www.icann.org/committees/security/sac035.pdf>.
-
-
-Author's Address
-
- Ray Bellis
- Nominet UK
- Edmund Halley Road
- Oxford OX4 4DQ
- United Kingdom
-
- Phone: +44 1865 332211
- Email: ray.bellis@nominet.org.uk
- URI: http://www.nominet.org.uk/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bellis Expires October 25, 2009 [Page 13]
-\f
+++ /dev/null
-
-
-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
-
+++ /dev/null
-
-
-
-DNSEXT D. Blacka
-Internet-Draft VeriSign, Inc.
-Intended status: Standards Track April 7, 2006
-Expires: October 9, 2006
-
-
- DNSSEC Experiments
- draft-ietf-dnsext-dnssec-experiments-03
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on October 9, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 1]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Abstract
-
- This document describes a methodology for deploying alternate, non-
- backwards-compatible, DNSSEC methodologies in an experimental fashion
- without disrupting the deployment of standard DNSSEC.
-
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 8
- 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9
- 7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
- 10.2. Informative References . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 2]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system (RFC 1035
- [5]) and the DNS security extensions ([2], [3], and [4] is assumed.
-
- The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [1].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 3]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-2. Overview
-
- Historically, experimentation with DNSSEC alternatives has been a
- problematic endeavor. There has typically been a desire to both
- introduce non-backwards-compatible changes to DNSSEC and to try these
- changes on real zones in the public DNS. This creates a problem when
- the change to DNSSEC would make all or part of the zone using those
- changes appear bogus (bad) or otherwise broken to existing security-
- aware resolvers.
-
- This document describes a standard methodology for setting up DNSSEC
- experiments. This methodology addresses the issue of co-existence
- with standard DNSSEC and DNS by using unknown algorithm identifiers
- to hide the experimental DNSSEC protocol modifications from standard
- security-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 4]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-3. Experiments
-
- When discussing DNSSEC experiments, it is necessary to classify these
- experiments into two broad categories:
-
- Backwards-Compatible: describes experimental changes that, while not
- strictly adhering to the DNSSEC standard, are nonetheless
- interoperable with clients and servers that do implement the
- DNSSEC standard.
-
- Non-Backwards-Compatible: describes experiments that would cause a
- standard security-aware resolver to (incorrectly) determine that
- all or part of a zone is bogus, or to otherwise not interoperate
- with standard DNSSEC clients and servers.
-
- Not included in these terms are experiments with the core DNS
- protocol itself.
-
- The methodology described in this document is not necessary for
- backwards-compatible experiments, although it certainly may be used
- if desired.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 5]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-4. Method
-
- The core of the methodology is the use of strictly unknown algorithm
- identifiers when signing the experimental zone, and more importantly,
- having only unknown algorithm identifiers in the DS records for the
- delegation to the zone at the parent.
-
- This technique works because of the way DNSSEC-compliant validators
- are expected to work in the presence of a DS set with only unknown
- algorithm identifiers. From [4], Section 5.2:
-
- If the validator does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
- And further:
-
- If the resolver does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver will not be able to
- verify the authentication path to the child zone. In this case,
- the resolver SHOULD treat the child zone as if it were unsigned.
-
- While this behavior isn't strictly mandatory (as marked by MUST), it
- is likely that a validator would implement this behavior, or, more to
- the point, it would handle this situation in a safe way (see below
- (Section 6).)
-
- Because we are talking about experiments, it is RECOMMENDED that
- private algorithm numbers be used (see [3], appendix A.1.1. Note
- that secure handling of private algorithms requires special handing
- by the validator logic. See [6] for further details.) Normally,
- instead of actually inventing new signing algorithms, the recommended
- path is to create alternate algorithm identifiers that are aliases
- for the existing, known algorithms. While, strictly speaking, it is
- only necessary to create an alternate identifier for the mandatory
- algorithms, it is suggested that all optional defined algorithms be
- aliased as well.
-
- It is RECOMMENDED that for a particular DNSSEC experiment, a
- particular domain name base is chosen for all new algorithms, then
- the algorithm number (or name) is prepended to it. For example, for
- experiment A, the base name of "dnssec-experiment-a.example.com" is
- chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
- defined to be "3.dnssec-experiment-a.example.com" and
- "5.dnssec-experiment-a.example.com". However, any unique identifier
-
-
-
-Blacka Expires October 9, 2006 [Page 6]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
- will suffice.
-
- Using this method, resolvers (or, more specifically, DNSSEC
- validators) essentially indicate their ability to understand the
- DNSSEC experiment's semantics by understanding what the new algorithm
- identifiers signify.
-
- This method creates two classes of security-aware servers and
- resolvers: servers and resolvers that are aware of the experiment
- (and thus recognize the experiment's algorithm identifiers and
- experimental semantics), and servers and resolvers that are unaware
- of the experiment.
-
- This method also precludes any zone from being both in an experiment
- and in a classic DNSSEC island of security. That is, a zone is
- either in an experiment and only experimentally validatable, or it is
- not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 7]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-5. Defining an Experiment
-
- The DNSSEC experiment MUST define the particular set of (previously
- unknown) algorithm identifiers that identify the experiment, and
- define what each unknown algorithm identifier means. Typically,
- unless the experiment is actually experimenting with a new DNSSEC
- algorithm, this will be a mapping of private algorithm identifiers to
- existing, known algorithms.
-
- Normally the experiment will choose a DNS name as the algorithm
- identifier base. This DNS name SHOULD be under the control of the
- authors of the experiment. Then the experiment will define a mapping
- between known mandatory and optional algorithms into this private
- algorithm identifier space. Alternately, the experiment MAY use the
- OID private algorithm space instead (using algorithm number 254), or
- MAY choose non-private algorithm numbers, although this would require
- an IANA allocation.
-
- For example, an experiment might specify in its description the DNS
- name "dnssec-experiment-a.example.com" as the base name, and declare
- that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
- algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
- alias of DNSSEC algorithm 5 (RSASHA1).
-
- Resolvers MUST only recognize the experiment's semantics when present
- in a zone signed by one or more of these algorithm identifiers. This
- is necessary to isolate the semantics of one experiment from any
- others that the resolver might understand.
-
- In general, resolvers involved in the experiment are expected to
- understand both standard DNSSEC and the defined experimental DNSSEC
- protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 8]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-6. Considerations
-
- There are a number of considerations with using this methodology.
-
- 1. Under some circumstances, it may be that the experiment will not
- be sufficiently masked by this technique and may cause resolution
- problem for resolvers not aware of the experiment. For instance,
- the resolver may look at a non-validatable response and conclude
- that the response is bogus, either due to local policy or
- implementation details. This is not expected to be a common
- case, however.
-
- 2. It will not be possible for security-aware resolvers unaware of
- the experiment to build a chain of trust through an experimental
- zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 9]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-7. Use in Non-Experiments
-
- This general methodology MAY be used for non-backwards compatible
- DNSSEC protocol changes that start out as or become standards. In
- this case:
-
- o The protocol change SHOULD use public IANA allocated algorithm
- identifiers instead of private algorithm identifiers. This will
- help identify the protocol change as a standard, rather than an
- experiment.
-
- o Resolvers MAY recognize the protocol change in zones not signed
- (or not solely signed) using the new algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 10]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-8. Security Considerations
-
- Zones using this methodology will be considered insecure by all
- resolvers except those aware of the experiment. It is not generally
- possible to create a secure delegation from an experimental zone that
- will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 11]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-9. IANA Considerations
-
- This document has no IANA actions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 12]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-10. References
-
-10.1. Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
-10.2. Informative References
-
- [5] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [6] Austein, R. and S. Weiler, "Clarifications and Implementation
- Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
- (work in progress), January 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 13]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Author's Address
-
- David Blacka
- VeriSign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- Email: davidb@verisign.com
- URI: http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 14]
-\f
-Internet-Draft DNSSEC Experiments April 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-Blacka Expires October 9, 2006 [Page 15]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-This Internet-Draft, draft-ietf-dnsext-forgery-resilience-01.txt, has expired, and has been deleted
-from the Internet-Drafts directory. An Internet-Draft expires 185 days from
-the date that it is posted unless it is replaced by an updated version, or the
-Secretariat has been notified that the document is under official review by the
-IESG or has been passed to the RFC Editor for review and/or publication as an
-RFC. This Internet-Draft was not published as an RFC.
-
-Internet-Drafts are not archival documents, and copies of Internet-Drafts that have
-been deleted from the directory are not available. The Secretariat does not have
-any information regarding the future plans of the author(s) or working group, if
-applicable, with respect to this deleted Internet-Draft. For more information, or
-to request a copy of the document, please contact the author(s) directly.
-
-Draft Author(s):
-Remco van Mook <remco@virtu.nl>,
-Bert Hubert <bert.hubert@netherlabs.nl>
+++ /dev/null
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Bernard Aboba
-INTERNET-DRAFT Dave Thaler
-Category: Standards Track Levon Esibov
-<draft-ietf-dnsext-mdns-46.txt> Microsoft Corporation
-16 April 2006
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on October 15, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2006.
-
-Abstract
-
- The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
- name resolution in scenarios in which conventional DNS name
- resolution is not possible. LLMNR supports all current and future
- DNS formats, types and classes, while operating on a separate port
- from DNS, and with a distinct resolver cache. Since LLMNR only
- operates on the local link, it cannot be considered a substitute for
- DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name Resolution Using LLMNR ........................... 4
- 2.1 LLMNR Packet Format ............................. 5
- 2.2 Sender Behavior ................................. 8
- 2.3 Responder Behavior .............................. 8
- 2.4 Unicast Queries and Responses ................... 11
- 2.5 Off-link Detection .............................. 11
- 2.6 Responder Responsibilities ...................... 12
- 2.7 Retransmission and Jitter ....................... 13
- 2.8 DNS TTL ......................................... 14
- 2.9 Use of the Authority and Additional Sections .... 14
-3. Usage model ........................................... 15
- 3.1 LLMNR Configuration ............................. 16
-4. Conflict Resolution ................................... 18
- 4.1 Uniqueness Verification ......................... 18
- 4.2 Conflict Detection and Defense .................. 19
- 4.3 Considerations for Multiple Interfaces .......... 20
- 4.4 API issues ...................................... 22
-5. Security Considerations ............................... 22
- 5.1 Denial of Service ............................... 22
- 5.2 Spoofing ...............,........................ 23
- 5.3 Authentication .................................. 24
- 5.4 Cache and Port Separation ....................... 24
-6. IANA considerations ................................... 25
-7. Constants ............................................. 25
-8. References ............................................ 26
- 8.1 Normative References ............................ 26
- 8.2 Informative References .......................... 26
-Acknowledgments .............................................. 28
-Authors' Addresses ........................................... 28
-Intellectual Property Statement .............................. 29
-Disclaimer of Validity ....................................... 29
-Copyright Statement .......................................... 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which is based on the DNS packet format and supports all current and
- future DNS formats, types and classes. LLMNR operates on a separate
- port from the Domain Name System (DNS), with a distinct resolver
- cache.
-
- Since LLMNR only operates on the local link, it cannot be considered
- a substitute for DNS. Link-scope multicast addresses are used to
- prevent propagation of LLMNR traffic across routers, potentially
- flooding the network. LLMNR queries can also be sent to a unicast
- address, as described in Section 2.4.
-
- Propagation of LLMNR packets on the local link is considered
- sufficient to enable name resolution in small networks. In such
- networks, if a network has a gateway, then typically the network is
- able to provide DNS server configuration. Configuration issues are
- discussed in Section 3.1.
-
- In the future, it may be desirable to consider use of multicast name
- resolution with multicast scopes beyond the link-scope. This could
- occur if LLMNR deployment is successful, the need arises for
- multicast name resolution beyond the link-scope, or multicast routing
- becomes ubiquitous. For example, expanded support for multicast name
- resolution might be required for mobile ad-hoc networks.
-
- Once we have experience in LLMNR deployment in terms of
- administrative issues, usability and impact on the network, it will
- be possible to reevaluate which multicast scopes are appropriate for
- use with multicast name resolution. IPv4 administratively scoped
- multicast usage is specified in "Administratively Scoped IP
- Multicast" [RFC2365].
-
- Service discovery in general, as well as discovery of DNS servers
- using LLMNR in particular, is outside of the scope of this document,
- as is name resolution over non-multicast capable media.
-
-1.1. Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
- and "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-1.2. Terminology
-
- This document assumes familiarity with DNS terminology defined in
- [RFC1035]. Other terminology used in this document includes:
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An LLMNR responder considers one of its addresses reachable over a
- link if it will respond to an ARP or Neighbor Discovery query for
- that address received on that link.
-
-Responder
- A host that listens to LLMNR queries, and responds to those for
- which it is authoritative.
-
-Sender
- A host that sends an LLMNR query.
-
-UNIQUE
- There are some scenarios when multiple responders may respond to
- the same query. There are other scenarios when only one responder
- may respond to a query. Names for which only a single responder is
- anticipated are referred to as UNIQUE. Name uniqueness is
- configured on the responder, and therefore uniqueness verification
- is the responder's responsibility.
-
-2. Name Resolution Using LLMNR
-
- LLMNR queries are sent to and received on port 5355. The IPv4 link-
- scope multicast address a given responder listens to, and to which a
- sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
- address a given responder listens to, and to which a sender sends all
- queries, is FF02:0:0:0:0:0:1:3.
-
- Typically a host is configured as both an LLMNR sender and a
- responder. A host MAY be configured as a sender, but not a
- responder. However, a host configured as a responder MUST act as a
- sender, if only to verify the uniqueness of names as described in
- Section 4. This document does not specify how names are chosen or
- configured. This may occur via any mechanism, including DHCPv4
- [RFC2131] or DHCPv6 [RFC3315].
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] An LLMNR sender sends an LLMNR query to the link-scope
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- multicast address(es), unless a unicast query is indicated,
- as specified in Section 2.4.
-
- [b] A responder responds to this query only if it is authoritative
- for the name in the query. A responder responds to a
- multicast query by sending a unicast UDP response to the sender.
- Unicast queries are responded to as indicated in Section 2.4.
-
- [c] Upon reception of the response, the sender processes it.
-
- The sections that follow provide further details on sender and
- responder behavior.
-
-2.1. LLMNR Packet Format
-
- LLMNR is based on the DNS packet format defined in [RFC1035] Section
- 4 for both queries and responses. LLMNR implementations SHOULD send
- UDP queries and responses only as large as are known to be
- permissible without causing fragmentation. When in doubt a maximum
- packet size of 512 octets SHOULD be used. LLMNR implementations MUST
- accept UDP queries and responses as large as the smaller of the link
- MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
- octets for the header, VLAN tag and CRC).
-
-2.1.1. LLMNR Header Format
-
- LLMNR queries and responses utilize the DNS header format defined in
- [RFC1035] with exceptions noted below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value. For advice on generation of pseudo-random values, please
- consult [RFC1750].
-
-QR Query/Response. A one bit field, which if set indicates that the
- message is an LLMNR response; if clear then the message is an LLMNR
- query.
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-C Conflict. When set within a request, the 'C'onflict bit indicates
- that a sender has received multiple LLMNR responses to this query.
- In an LLMNR response, if the name is considered UNIQUE, then the
- 'C' bit is clear, otherwise it is set. LLMNR senders do not
- retransmit queries with the 'C' bit set. Responders MUST NOT
- respond to LLMNR queries with the 'C' bit set, but may start the
- uniqueness verification process, as described in Section 4.2.
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set in an LLMNR response,
- then the sender SHOULD resend the LLMNR query over TCP using the
- unicast address of the responder as the destination address. If
- the sender receives a response to the TCP query, then it SHOULD
- discard the UDP response with the TC bit set. See [RFC2181] and
- Section 2.4 of this specification for further discussion of the TC
- bit.
-
-T Tentative. The 'T'entative bit is set in a response if the
- responder is authoritative for the name, but has not yet verified
- the uniqueness of the name. A responder MUST ignore the 'T' bit in
- a query, if set. A response with the 'T' bit set is silently
- discarded by the sender, except if it is a uniqueness query, in
- which case a conflict has been detected and a responder MUST
- resolve the conflict as described in Section 4.1.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the sender MUST set RCODE to zero;
- the responder ignores the RCODE and assumes it to be zero. The
- response to a multicast LLMNR query MUST have RCODE set to zero. A
- sender MUST silently discard an LLMNR response with a non-zero
- RCODE sent in response to a multicast query.
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferable to not
- sending a response, since it enables errors to be diagnosed. This
- may be required, for example, when an LLMNR query includes a TSIG
- RR in the additional section, and the responder encounters a
- problem that requires returning a non-zero RCODE. TSIG error
- conditions defined in [RFC2845] include a TSIG RR in an
- unacceptable position (RCODE=1) or a TSIG RR which does not
- validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16 (BADSIG)).
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9. LLMNR
- responders MUST silently discard LLMNR queries with NSCOUNT not
- equal to zero.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender Behavior
-
- A sender MAY send an LLMNR query for any legal resource record type
- (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
- As described in Section 2.4, a sender MAY also send a unicast query.
-
- The sender MUST anticipate receiving no replies to some LLMNR
- queries, in the event that no responders are available within the
- link-scope. If no response is received, a resolver treats it as a
- response that the name does not exist (RCODE=3 is returned). A
- sender can handle duplicate responses by discarding responses with a
- source IP address and ID field that duplicate a response already
- received.
-
- When multiple valid LLMNR responses are received with the 'C' bit
- set, they SHOULD be concatenated and treated in the same manner that
- multiple RRs received from the same DNS server would be. However,
- responses with the 'C' bit set SHOULD NOT be concatenated with
- responses with the 'C' bit clear; instead, only the responses with
- the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
- received along with error response(s), then the error responses are
- silently discarded.
-
- Since the responder may order the RRs in the response so as to
- indicate preference, the sender SHOULD preserve ordering in the
- response to the querying application.
-
-2.3. Responder Behavior
-
- An LLMNR response MUST be sent to the sender via unicast.
-
- Upon configuring an IP address, responders typically will synthesize
- corresponding A, AAAA and PTR RRs so as to be able to respond to
- LLMNR queries for these RRs. An SOA RR is synthesized only when a
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responder has another RR in addition to the SOA RR; the SOA RR MUST
- NOT be the only RR that a responder has. However, in general whether
- RRs are manually or automatically created is an implementation
- decision.
-
- For example, a host configured to have computer name "host1" and to
- be a member of the "example.com" domain, and with IPv4 address
- 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
- authoritative for the following records:
-
- host1. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- host1.example.com. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- 1.2.0.192.in-addr.arpa. IN PTR host1.
- IN PTR host1.example.com.
-
- 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
- ip6.arpa IN PTR host1. (line split for formatting reasons)
- IN PTR host1.example.com.
-
- An LLMNR responder might be further manually configured with the name
- of a local mail server with an MX RR included in the "host1." and
- "host1.example.com." records.
-
- In responding to queries:
-
-[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
- address(es) defined in Section 2, and on TCP port 5355 on the
- unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses MUST always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups, with the exception of queries with the 'C' bit
- set, which do not elicit a response.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[e] Responders MUST NOT respond using data from the LLMNR or DNS
- resolver cache.
-
-[f] If a DNS server is running on a host that supports LLMNR, the DNS
- server MUST respond to LLMNR queries only for the RRSets relating
- to the host on which the server is running, but MUST NOT respond
- for other records for which the server is authoritative. DNS
- servers also MUST NOT send LLMNR queries in order to resolve DNS
- queries.
-
-[g] If a responder is authoritative for a name, it MUST respond with
- RCODE=0 and an empty answer section, if the type of query does not
- match a RR that the responder has.
-
- As an example, a host configured to respond to LLMNR queries for the
- name "foo.example.com." is authoritative for the name
- "foo.example.com.". On receiving an LLMNR query for an A RR with the
- name "foo.example.com." the host authoritatively responds with A
- RR(s) that contain IP address(es) in the RDATA of the resource
- record. If the responder has a AAAA RR, but no A RR, and an A RR
- query is received, the responder would respond with RCODE=0 and an
- empty answer section.
-
- In conventional DNS terminology a DNS server authoritative for a zone
- is authoritative for all the domain names under the zone apex except
- for the branches delegated into separate zones. Contrary to
- conventional DNS terminology, an LLMNR responder is authoritative
- only for the zone apex.
-
- For example the host "foo.example.com." is not authoritative for the
- name "child.foo.example.com." unless the host is configured with
- multiple names, including "foo.example.com." and
- "child.foo.example.com.". As a result, "foo.example.com." cannot
- reply to an LLMNR query for "child.foo.example.com." with RCODE=3
- (authoritative name error). The purpose of limiting the name
- authority scope of a responder is to prevent complications that could
- be caused by coexistence of two or more hosts with the names
- representing child and parent (or grandparent) nodes in the DNS tree,
- for example, "foo.example.com." and "child.foo.example.com.".
-
- Without the restriction on authority an LLMNR query for an A resource
- record for the name "child.foo.example.com." would result in two
- authoritative responses: RCODE=3 (authoritative name error) received
- from "foo.example.com.", and a requested A record - from
- "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
- hosts could perform a dynamic update of the parent (or grandparent)
- zone with a delegation to a child zone; for example a host
- "child.foo.example.com." could send a dynamic update for the NS and
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- glue A record to "foo.example.com.". However, this approach
- significantly complicates implementation of LLMNR and would not be
- acceptable for lightweight hosts.
-
-2.4. Unicast Queries and Responses
-
- Unicast queries SHOULD be sent when:
-
- [a] A sender repeats a query after it received a response
- with the TC bit set to the previous LLMNR multicast query, or
-
- [b] The sender queries for a PTR RR of a fully formed IP address
- within the "in-addr.arpa" or "ip6.arpa" zones.
-
- Unicast LLMNR queries MUST be done using TCP and the responses MUST
- be sent using the same TCP connection as the query. Senders MUST
- support sending TCP queries, and responders MUST support listening
- for TCP queries. If the sender of a TCP query receives a response to
- that query not using TCP, the response MUST be silently discarded.
-
- Unicast UDP queries MUST be silently discarded.
-
- A unicast PTR RR query for an off-link address will not elicit a
- response, but instead an ICMP TTL or Hop Limit exceeded message will
- be received. An implementation receiving an ICMP message in response
- to a TCP connection setup attempt can return immediately, treating
- this as a response that no such name exists (RCODE=3 is returned).
- An implementation that cannot process ICMP messages MAY send
- multicast UDP queries for PTR RRs. Since TCP implementations will
- not retransmit prior to RTOmin, a considerable period will elapse
- before TCP retransmits multiple times, resulting in a long timeout
- for TCP PTR RR queries sent to an off-link destination.
-
-2.5. "Off link" Detection
-
- A sender MUST select a source address for LLMNR queries that is
- assigned on the interface on which the query is sent. The
- destination address of an LLMNR query MUST be a link-scope multicast
- address or a unicast address.
-
- A responder MUST select a source address for responses that is
- assigned on the interface on which the query was received. The
- destination address of an LLMNR response MUST be a unicast address.
-
- On receiving an LLMNR query, the responder MUST check whether it was
- sent to a LLMNR multicast addresses defined in Section 2. If it was
- sent to another multicast address, then the query MUST be silently
- discarded.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- Section 2.4 discusses use of TCP for LLMNR queries and responses. In
- composing an LLMNR query using TCP, the sender MUST set the Hop Limit
- field in the IPv6 header and the TTL field in the IPv4 header of the
- response to one (1). The responder SHOULD set the TTL or Hop Limit
- settings on the TCP listen socket to one (1) so that SYN-ACK packets
- will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
- prevents an incoming connection from off-link since the sender will
- not receive a SYN-ACK from the responder.
-
- For UDP queries and responses, the Hop Limit field in the IPv6 header
- and the TTL field in the IPV4 header MAY be set to any value.
- However, it is RECOMMENDED that the value 255 be used for
- compatibility with early implementations of [RFC3927].
-
- Implementation note:
-
- In the sockets API for IPv4 [POSIX], the IP_TTL and
- IP_MULTICAST_TTL socket options are used to set the TTL of
- outgoing unicast and multicast packets. The IP_RECVTTL socket
- option is available on some platforms to retrieve the IPv4 TTL of
- received packets with recvmsg(). [RFC2292] specifies similar
- options for setting and retrieving the IPv6 Hop Limit.
-
-2.6. Responder Responsibilities
-
- It is the responsibility of the responder to ensure that RRs returned
- in LLMNR responses MUST only include values that are valid on the
- local interface, such as IPv4 or IPv6 addresses valid on the local
- link or names defended using the mechanism described in Section 4.
- IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
- addresses are defined in [RFC2373]. In particular:
-
- [a] If a link-scope IPv6 address is returned in a AAAA RR,
- that address MUST be valid on the local link over which
- LLMNR is used.
-
- [b] If an IPv4 address is returned, it MUST be reachable
- through the link over which LLMNR is used.
-
- [c] If a name is returned (for example in a CNAME, MX
- or SRV RR), the name MUST be resolvable on the local
- link over which LLMNR is used.
-
- Where multiple addresses represent valid responses to a query, the
- order in which the addresses are returned is as follows:
-
- [d] If the source address of the query is a link-scope address,
- then the responder SHOULD include a link-scope address first
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- in the response, if available.
-
- [e] If the source address of the query is a routable address,
- then the responder MUST include a routable address first
- in the response, if available.
-
-2.7. Retransmission and Jitter
-
- An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
- when to retransmit an LLMNR query. An LLMNR sender SHOULD either
- estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
- high initial timeout. Suggested constants are described in Section
- 7.
-
- If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
- then a sender SHOULD repeat the transmission of the query in order to
- assure that it was received by a host capable of responding to it.
- An LLMNR query SHOULD NOT be sent more than three times.
-
- Where LLMNR queries are sent using TCP, retransmission is handled by
- the transport layer. Queries with the 'C' bit set MUST be sent using
- multicast UDP and MUST NOT be retransmitted.
-
- An LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
- has been received, or if it is necessary to collect all potential
- responses, such as if a uniqueness verification query is being made.
- Otherwise an LLMNR sender SHOULD consider a multicast query answered
- after the first response is received, if that response has the 'C'
- bit clear.
-
- However, if the first response has the 'C' bit set, then the sender
- SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect
- all possible responses. When multiple valid answers are received,
- they may first be concatenated, and then treated in the same manner
- that multiple RRs received from the same DNS server would. A unicast
- query sender considers the query answered after the first response is
- received.
-
- Since it is possible for a response with the 'C' bit clear to be
- followed by a response with the 'C' bit set, an LLMNR sender SHOULD
- be prepared to process additional responses for the purposes of
- conflict detection, even after it has considered a query answered.
-
- In order to avoid synchronization, the transmission of each LLMNR
- query and response SHOULD delayed by a time randomly selected from
- the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- responders responding with names which they have previously
- determined to be UNIQUE (see Section 4 for details).
-
-2.8. DNS TTL
-
- The responder should insert a pre-configured TTL value in the records
- returned in an LLMNR response. A default value of 30 seconds is
- RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
- networks), the TTL value may need to be reduced.
-
- Due to the TTL minimalization necessary when caching an RRset, all
- TTLs in an RRset MUST be set to the same value.
-
-2.9. Use of the Authority and Additional Sections
-
- Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
- concept of delegation. In LLMNR, the NS resource record type may be
- stored and queried for like any other type, but it has no special
- delegation semantics as it does in the DNS. Responders MAY have NS
- records associated with the names for which they are authoritative,
- but they SHOULD NOT include these NS records in the authority
- sections of responses.
-
- Responders SHOULD insert an SOA record into the authority section of
- a negative response, to facilitate negative caching as specified in
- [RFC2308]. The TTL of this record is set from the minimum of the
- MINIMUM field of the SOA record and the TTL of the SOA itself, and
- indicates how long a resolver may cache the negative answer. The
- owner name of the SOA record (MNAME) MUST be set to the query name.
- The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
- by senders. Negative responses without SOA records SHOULD NOT be
- cached.
-
- In LLMNR, the additional section is primarily intended for use by
- EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
- senders MAY only include pseudo RR-types in the additional section of
- a query; unless the 'C' bit is set, responders MUST ignore the
- additional section of queries containing other RR types.
-
- In queries where the 'C' bit is set, the sender SHOULD include the
- conflicting RRs in the additional section. Since conflict
- notifications are advisory, responders SHOULD log information from
- the additional section, but otherwise MUST ignore the additional
- section.
-
- Senders MUST NOT cache RRs from the authority or additional section
- of a response as answers, though they may be used for other purposes
- such as negative caching.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-3. Usage Model
-
- LLMNR is a peer-to-peer name resolution protocol that is not intended
- as a replacement for DNS; rather, it enables name resolution in
- scenarios in which conventional DNS name resolution is not possible.
- This includes situations in which hosts are not configured with the
- address of a DNS server; where the DNS server is unavailable or
- unreachable; where there is no DNS server authoritative for the name
- of a host, or where the authoritative DNS server does not have the
- desired RRs.
-
- By default, an LLMNR sender SHOULD send LLMNR queries only for
- single-label names. In order to reduce unnecessary DNS queries, stub
- resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS
- queries for single-label names. An LLMNR sender SHOULD NOT be
- enabled to send a query for any name, except where security
- mechanisms (described in Section 5.3) can be utilized.
-
- Regardless of whether security mechanisms can be utilized, LLMNR
- queries SHOULD NOT be sent unless one of the following conditions are
- met:
-
- [1] No manual or automatic DNS configuration has been performed.
- If DNS server address(es) have been configured, a
- host SHOULD attempt to reach DNS servers over all protocols
- on which DNS server address(es) are configured, prior to sending
- LLMNR queries. For dual stack hosts configured with DNS server
- address(es) for one protocol but not another, this implies that
- DNS queries SHOULD be sent over the protocol configured with
- a DNS server, prior to sending LLMNR queries.
-
- [2] All attempts to resolve the name via DNS on all interfaces
- have failed after exhausting the searchlist. This can occur
- because DNS servers did not respond, or because they
- responded to DNS queries with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section. Where a
- single resolver call generates DNS queries for A and AAAA RRs,
- an implementation MAY choose not to send LLMNR queries if any
- of the DNS queries is successful. An LLMNR query SHOULD only
- be sent for the originally requested name; a searchlist
- is not used to form additional LLMNR queries.
-
- Since LLMNR is a secondary name resolution mechanism, its usage is in
- part determined by the behavior of DNS implementations. In general,
- robust DNS resolver implementations are more likely to avoid
- unnecessary LLMNR queries.
-
- As noted in [DNSPerf], even when DNS servers are configured, a
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- significant fraction of DNS queries do not receive a response, or
- result in negative responses due to missing inverse mappings or NS
- records that point to nonexistent or inappropriate hosts. This has
- the potential to result in a large number of unnecessary LLMNR
- queries.
-
- [RFC1536] describes common DNS implementation errors and fixes. If
- the proposed fixes are implemented, unnecessary LLMNR queries will be
- reduced substantially, and so implementation of [RFC1536] is
- recommended.
-
- For example, [RFC1536] Section 1 describes issues with retransmission
- and recommends implementation of a retransmission policy based on
- round trip estimates, with exponential back-off. [RFC1536] Section 4
- describes issues with failover, and recommends that resolvers try
- another server when they don't receive a response to a query. These
- policies are likely to avoid unnecessary LLMNR queries.
-
- [RFC1536] Section 3 describes zero answer bugs, which if addressed
- will also reduce unnecessary LLMNR queries.
-
- [RFC1536] Section 6 describes name error bugs and recommended
- searchlist processing that will reduce unnecessary RCODE=3
- (authoritative name) errors, thereby also reducing unnecessary LLMNR
- queries.
-
- If error responses are received from both DNS and LLMNR, then the
- lowest RCODE value should be returned. For example, if either DNS or
- LLMNR receives a response with RCODE=0, then this should returned to
- the caller.
-
-3.1. LLMNR Configuration
-
- LLMNR usage MAY be configured manually or automatically on a per
- interface basis. By default, LLMNR responders SHOULD be enabled on
- all interfaces, at all times. Enabling LLMNR for use in situations
- where a DNS server has been configured will result in a change in
- default behavior without a simultaneous update to configuration
- information. Where this is considered undesirable, LLMNR SHOULD NOT
- be enabled by default, so that hosts will neither listen on the link-
- scope multicast address, nor will they send queries to that address.
-
- Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
- possible for a dual stack host to be configured with the address of a
- DNS server over IPv4, while remaining unconfigured with a DNS server
- suitable for use over IPv6.
-
- In these situations, a dual stack host will send AAAA queries to the
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- configured DNS server over IPv4. However, an IPv6-only host
- unconfigured with a DNS server suitable for use over IPv6 will be
- unable to resolve names using DNS. Automatic IPv6 DNS configuration
- mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
- deployed, and not all DNS servers support IPv6. Therefore lack of
- IPv6 DNS configuration may be a common problem in the short term, and
- LLMNR may prove useful in enabling link-local name resolution over
- IPv6.
-
- Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
- IPv6-only hosts may not be configured with a DNS server. Where there
- is no DNS server authoritative for the name of a host or the
- authoritative DNS server does not support dynamic client update over
- IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
- be able to do DNS dynamic update, and other hosts will not be able to
- resolve its name.
-
- For example, if the configured DNS server responds to a AAAA RR query
- sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
- RCODE=0 and an empty answer section, then a AAAA RR query sent using
- LLMNR over IPv6 may be successful in resolving the name of an
- IPv6-only host on the local link.
-
- Similarly, if a DHCPv4 server is available providing DNS server
- configuration, and DNS server(s) exist which are authoritative for
- the A RRs of local hosts and support either dynamic client update
- over IPv4 or DHCPv4-based dynamic update, then the names of local
- IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
- DNS server is authoritative for the names of local hosts, or the
- authoritative DNS server(s) do not support dynamic update, then LLMNR
- enables linklocal name resolution over IPv4.
-
- Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
- configure LLMNR on an interface. The LLMNR Enable Option, described
- in [LLMNREnable], can be used to explicitly enable or disable use of
- LLMNR on an interface. The LLMNR Enable Option does not determine
- whether or in which order DNS itself is used for name resolution.
- The order in which various name resolution mechanisms should be used
- can be specified using the Name Service Search Option (NSSO) for DHCP
- [RFC2937], using the LLMNR Enable Option code carried in the NSSO
- data.
-
- It is possible that DNS configuration mechanisms will go in and out
- of service. In these circumstances, it is possible for hosts within
- an administrative domain to be inconsistent in their DNS
- configuration.
-
- For example, where DHCP is used for configuring DNS servers, one or
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- more DHCP servers can fail. As a result, hosts configured prior to
- the outage will be configured with a DNS server, while hosts
- configured after the outage will not. Alternatively, it is possible
- for the DNS configuration mechanism to continue functioning while
- configured DNS servers fail.
-
- An outage in the DNS configuration mechanism may result in hosts
- continuing to use LLMNR even once the outage is repaired. Since
- LLMNR only enables linklocal name resolution, this represents a
- degradation in capabilities. As a result, hosts without a configured
- DNS server may wish to periodically attempt to obtain DNS
- configuration if permitted by the configuration mechanism in use. In
- the absence of other guidance, a default retry interval of one (1)
- minute is RECOMMENDED.
-
-4. Conflict Resolution
-
- By default, a responder SHOULD be configured to behave as though its
- name is UNIQUE on each interface on which LLMNR is enabled. However,
- it is also possible to configure multiple responders to be
- authoritative for the same name. For example, multiple responders
- MAY respond to a query for an A or AAAA type record for a cluster
- name (assigned to multiple hosts in the cluster).
-
- To detect duplicate use of a name, an administrator can use a name
- resolution utility which employs LLMNR and lists both responses and
- responders. This would allow an administrator to diagnose behavior
- and potentially to intervene and reconfigure LLMNR responders who
- should not be configured to respond to the same name.
-
-4.1. Uniqueness Verification
-
- Prior to sending an LLMNR response with the 'T' bit clear, a
- responder configured with a UNIQUE name MUST verify that there is no
- other host within the scope of LLMNR query propagation that is
- authoritative for the same name on that interface.
-
- Once a responder has verified that its name is UNIQUE, if it receives
- an LLMNR query for that name, with the 'C' bit clear, it MUST
- respond, with the 'T' bit clear. Prior to verifying that its name is
- UNIQUE, a responder MUST set the 'T' bit in responses.
-
- Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive
- during sleep)
- - is configured to respond to LLMNR queries on an interface
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- enabled for transmission and reception of IP traffic
- - is configured to respond to LLMNR queries using additional
- UNIQUE resource records
- - verifies the acquisition of a new IP address and configuration
- on an interface
-
- To verify uniqueness, a responder MUST send an LLMNR query with the
- 'C' bit clear, over all protocols on which it responds to LLMNR
- queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
- uniqueness of a name by sending a query for the name with type='ANY'.
-
- If no response is received, the sender retransmits the query, as
- specified in Section 2.7. If a response is received, the sender MUST
- check if the source address matches the address of any of its
- interfaces; if so, then the response is not considered a conflict,
- since it originates from the sender. To avoid triggering conflict
- detection, a responder that detects that it is connected to the same
- link on multiple interfaces SHOULD set the 'C' bit in responses.
-
- If a response is received with the 'T' bit clear, the responder MUST
- NOT use the name in response to LLMNR queries received over any
- protocol (IPv4 or IPv6). If a response is received with the 'T' bit
- set, the responder MUST check if the source IP address in the
- response, interpreted as an unsigned integer, is less than the source
- IP address in the query. If so, the responder MUST NOT use the name
- in response to LLMNR queries received over any protocol (IPv4 or
- IPv6). For the purpose of uniqueness verification, the contents of
- the answer section in a response is irrelevant.
-
- Periodically carrying out uniqueness verification in an attempt to
- detect name conflicts is not necessary, wastes network bandwidth, and
- may actually be detrimental. For example, if network links are
- joined only briefly, and are separated again before any new
- communication is initiated, temporary conflicts are benign and no
- forced reconfiguration is required. LLMNR responders SHOULD NOT
- periodically attempt uniqueness verification.
-
-4.2. Conflict Detection and Defense
-
- Hosts on disjoint network links may configure the same name for use
- with LLMNR. If these separate network links are later joined or
- bridged together, then there may be multiple hosts which are now on
- the same link, trying to use the same name.
-
- In order to enable ongoing detection of name conflicts, when an LLMNR
- sender receives multiple LLMNR responses to a query, it MUST check if
- the 'C' bit is clear in any of the responses. If so, the sender
- SHOULD send another query for the same name, type and class, this
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- time with the 'C' bit set, with the potentially conflicting resource
- records included in the additional section.
-
- Queries with the 'C' bit set are considered advisory and responders
- MUST verify the existence of a conflict before acting on it. A
- responder receiving a query with the 'C' bit set MUST NOT respond.
-
- If the query is for a UNIQUE name, then the responder MUST send its
- own query for the same name, type and class, with the 'C' bit clear.
- If a response is received, the sender MUST check if the source
- address matches the address of any of its interfaces; if so, then the
- response is not considered a conflict, since it originates from the
- sender. To avoid triggering conflict detection, a responder that
- detects that it is connected to the same link on multiple interfaces
- SHOULD set the 'C' bit in responses.
-
- An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
- log them. Upon detecting a conflict, an LLMNR responder MUST
- immediately stop using the conflicting name in response to LLMNR
- queries received over any supported protocol, if the source IP
- address in the response, interpreted as an unsigned integer, is less
- than the source IP address in the uniqueness verification query.
-
- After stopping the use of a name, the responder MAY elect to
- configure a new name. However, since name reconfiguration may be
- disruptive, this is not required, and a responder may have been
- configured to respond to multiple names so that alternative names may
- already be available. A host that has stopped the use of a name may
- attempt uniqueness verification again after the expiration of the TTL
- of the conflicting response.
-
-4.3. Considerations for Multiple Interfaces
-
- A multi-homed host may elect to configure LLMNR on only one of its
- active interfaces. In many situations this will be adequate.
- However, should a host need to configure LLMNR on more than one of
- its active interfaces, there are some additional precautions it MUST
- take. Implementers who are not planning to support LLMNR on multiple
- interfaces simultaneously may skip this section.
-
- Where a host is configured to issue LLMNR queries on more than one
- interface, each interface maintains its own independent LLMNR
- resolver cache, containing the responses to LLMNR queries.
-
- A multi-homed host checks the uniqueness of UNIQUE records as
- described in Section 4. The situation is illustrated in figure 1.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
- In this situation, the multi-homed myhost will probe for, and defend,
- its host name on both interfaces. A conflict will be detected on one
- interface, but not the other. The multi-homed myhost will not be
- able to respond with a host RR for "myhost" on the interface on the
- right (see Figure 1). The multi-homed host may, however, be
- configured to use the "myhost" name on the interface on the left.
-
- Since names are only unique per-link, hosts on different links could
- be using the same name. If an LLMNR client sends requests over
- multiple interfaces, and receives replies from more than one, the
- result returned to the client is defined by the implementation. The
- situation is illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
- If host myhost is configured to use LLMNR on both interfaces, it will
- send LLMNR queries on both interfaces. When host myhost sends a
- query for the host RR for name "A" it will receive a response from
- hosts on both interfaces.
-
- Host myhost cannot distinguish between the situation shown in Figure
- 2, and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
- This illustrates that the proposed name conflict resolution mechanism
- does not support detection or resolution of conflicts between hosts
- on different links. This problem can also occur with DNS when a
- multi-homed host is connected to two different networks with
- separated name spaces. It is not the intent of this document to
- address the issue of uniqueness of names within DNS.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-4.4. API Issues
-
- [RFC2553] provides an API which can partially solve the name
- ambiguity problem for applications written to use this API, since the
- sockaddr_in6 structure exposes the scope within which each scoped
- address exists, and this structure can be used for both IPv4 (using
- v4-mapped IPv6 addresses) and IPv6 addresses.
-
- Following the example in Figure 2, an application on 'myhost' issues
- the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
- ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
- interfaces and the resolver library will return a list containing
- multiple addrinfo structures, each with an associated sockaddr_in6
- structure. This list will thus contain the IPv4 and IPv6 addresses
- of both hosts responding to the name 'A'. Link-local addresses will
- have a sin6_scope_id value that disambiguates which interface is used
- to reach the address. Of course, to the application, Figures 2 and 3
- are still indistinguishable, but this API allows the application to
- communicate successfully with any address in the list.
-
-5. Security Considerations
-
- LLMNR is a peer-to-peer name resolution protocol designed for use on
- the local link. While LLMNR limits the vulnerability of responders
- to off-link senders, it is possible for an off-link responder to
- reach a sender.
-
- In scenarios such as public "hotspots" attackers can be present on
- the same link. These threats are most serious in wireless networks
- such as 802.11, since attackers on a wired network will require
- physical access to the network, while wireless attackers may mount
- attacks from a distance. Link-layer security such as [IEEE-802.11i]
- can be of assistance against these threats if it is available.
-
- This section details security measures available to mitigate threats
- from on and off-link attackers.
-
-5.1. Denial of Service
-
- Attackers may take advantage of LLMNR conflict detection by
- allocating the same name, denying service to other LLMNR responders
- and possibly allowing an attacker to receive packets destined for
- other hosts. By logging conflicts, LLMNR responders can provide
- forensic evidence of these attacks.
-
- An attacker may spoof LLMNR queries from a victim's address in order
- to mount a denial of service attack. Responders setting the IPv6 Hop
- Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- response may be able to reach the victim across the Internet.
-
- While LLMNR responders only respond to queries for which they are
- authoritative and LLMNR does not provide wildcard query support, an
- LLMNR response may be larger than the query, and an attacker can
- generate multiple responses to a query for a name used by multiple
- responders. A sender may protect itself against unsolicited
- responses by silently discarding them as rapidly as possible.
-
-5.2. Spoofing
-
- LLMNR is designed to prevent reception of queries sent by an off-link
- attacker. LLMNR requires that responders receiving UDP queries check
- that they are sent to a link-scope multicast address. However, it is
- possible that some routers may not properly implement link-scope
- multicast, or that link-scope multicast addresses may leak into the
- multicast routing system. To prevent successful setup of TCP
- connections by an off-link sender, responders receiving a TCP SYN
- reply with a TCP SYN-ACK with TTL set to one (1).
-
- While it is difficult for an off-link attacker to send an LLMNR query
- to a responder, it is possible for an off-link attacker to spoof a
- response to a query (such as an A or AAAA query for a popular
- Internet host), and by using a TTL or Hop Limit field larger than one
- (1), for the forged response to reach the LLMNR sender. Since the
- forged response will only be accepted if it contains a matching ID
- field, choosing a pseudo-random ID field within queries provides some
- protection against off-link responders.
-
- Since LLMNR queries can be sent when DNS server(s) do not respond, an
- attacker can execute a denial of service attack on the DNS server(s)
- and then poison the LLMNR cache by responding to an LLMNR query with
- incorrect information. As noted in "Threat Analysis of the Domain
- Name System (DNS)" [RFC3833] these threats also exist with DNS, since
- DNS response spoofing tools are available that can allow an attacker
- to respond to a query more quickly than a distant DNS server.
- However, while switched networks or link layer security may make it
- difficult for an on-link attacker to snoop unicast DNS queries,
- multicast LLMNR queries are propagated to all hosts on the link,
- making it possible for an on-link attacker to spoof LLMNR responses
- without having to guess the value of the ID field in the query.
-
- Since LLMNR queries are sent and responded to on the local-link, an
- attacker will need to respond more quickly to provide its own
- response prior to arrival of the response from a legitimate
- responder. If an LLMNR query is sent for an off-link host, spoofing
- a response in a timely way is not difficult, since a legitimate
- response will never be received.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- This vulnerability can be reduced by limiting use of LLMNR to
- resolution of single-label names as described in Section 3, or by
- implementation of authentication (see Section 5.3).
-
-5.3. Authentication
-
- LLMNR is a peer-to-peer name resolution protocol, and as a result,
- it is often deployed in situations where no trust model can be
- assumed. Where a pre-arranged security configuration is possible,
- the following security mechanisms may be used:
-
-[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
- [RFC2931] security mechanisms. "DNS Name Service based on Secure
- Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
- the use of TSIG to secure LLMNR, based on group keys. While group
- keys can be used to demonstrate membership in a group, they do not
- protect against forgery by an attacker that is a member of the
- group.
-
-[b] IPsec ESP with a null-transform MAY be used to authenticate unicast
- LLMNR queries and responses or LLMNR responses to multicast
- queries. In a small network without a certificate authority, this
- can be most easily accomplished through configuration of a group
- pre-shared key for trusted hosts. As with TSIG, this does not
- protect against forgery by an attacker with access to the group
- pre-shared key.
-
-[c] LLMNR implementations MAY support DNSSEC [RFC4033]. In order to
- support DNSSEC, LLMNR implementations MAY be configured with trust
- anchors, or they MAY make use of keys obtained from DNS queries.
- Since LLMNR does not support "delegated trust" (CD or AD bits),
- LLMNR implementations cannot make use of DNSSEC unless they are
- DNSSEC-aware and support validation. Unlike approaches [a] or [b],
- DNSSEC permits a responder to demonstrate ownership of a name, not
- just membership within a trusted group. As a result, it enables
- protection against forgery.
-
-5.4. Cache and Port Separation
-
- In order to prevent responses to LLMNR queries from polluting the DNS
- cache, LLMNR implementations MUST use a distinct, isolated cache for
- LLMNR on each interface. The use of separate caches is most
- effective when LLMNR is used as a name resolution mechanism of last
- resort, since this minimizes the opportunities for poisoning the
- LLMNR cache, and decreases reliance on it.
-
- LLMNR operates on a separate port from DNS, reducing the likelihood
- that a DNS server will unintentionally respond to an LLMNR query.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
- If LLMNR is given higher priority than DNS among the enabled name
- resolution mechanisms, a denial of service attack on the DNS server
- would not be necessary in order to poison the LLMNR cache, since
- LLMNR queries would be sent even when the DNS server is available.
- In addition, the LLMNR cache, once poisoned, would take precedence
- over the DNS cache, eliminating the benefits of cache separation. As
- a result, LLMNR SHOULD NOT be used as a primary name resolution
- mechanism.
-
-6. IANA Considerations
-
- LLMNR requires allocation of port 5355 for both TCP and UDP.
-
- LLMNR requires allocation of link-scope multicast IPv4 address
- 224.0.0.252, as well as link-scope multicast IPv6 address
- FF02:0:0:0:0:0:1:3.
-
- This specification creates two new name spaces: the LLMNR namespace
- and the reserved bits in the LLMNR header. The reserved bits in the
- LLMNR header are allocated by IETF Consensus, in accordance with BCP
- 26 [RFC2434].
-
- In order to to avoid creating any new administrative procedures,
- administration of the LLMNR namespace will piggyback on the
- administration of the DNS namespace.
-
- The rights to use a fully qualified domain name (FQDN) within LLMNR
- are obtained coincident with acquiring the rights to use that name
- within DNS. Those wishing to use a FQDN within LLMNR should first
- acquire the rights to use the corresponding FQDN within DNS. Using a
- FQDN within LLMNR without ownership of the corresponding name in DNS
- creates the possibility of conflict and therefore is discouraged.
-
- LLMNR responders may self-allocate a name within the single-label
- name space, first defined in [RFC1001]. Since single-label names are
- not unique, no registration process is required.
-
-7. Constants
-
- The following timing constants are used in this protocol; they are
- not intended to be user configurable.
-
- JITTER_INTERVAL 100 ms
- LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
- 100 ms (IEEE 802 media, including IEEE 802.11)
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-8. References
-
-8.1. Normative References
-
-[RFC1001] Auerbach, K. and A. Aggarwal, "Protocol Standard for a NetBIOS
- Service on a TCP/UDP Transport: Concepts and Methods", RFC
- 1001, March 1987.
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
-8.2. Informative References
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
- Caching", IEEE/ACM Transactions on Networking, Volume 10,
- Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- Internet draft (work in progress), draft-ietf-ipv6-dns-
- discovery-07.txt, October 2002.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 26]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[IEEE-802.11i]
- Institute of Electrical and Electronics Engineers, "Supplement
- to Standard for Telecommunications and Information Exchange
- Between Systems - LAN/MAN Specific Requirements - Part 11:
- Wireless LAN Medium Access Control (MAC) and Physical Layer
- (PHY) Specifications: Specification for Enhanced Security",
- IEEE 802.11i, July 2004.
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
- Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
- Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
- 2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 27]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirement", RFC 4033, March
- 2005.
-
-Acknowledgments
-
- This work builds upon original work done on multicast DNS by Bill
- Manning and Bill Woodcock. Bill Manning's work was funded under
- DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
- their contribution to the current specification. Constructive input
- has also been received from Mark Andrews, Rob Austein, Randy Bush,
- Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
- Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
- Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
- Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
- St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 706 6605
- EMail: bernarda@microsoft.com
-
- Dave Thaler
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 703 8835
- EMail: dthaler@microsoft.com
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 28]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 29]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 16 April 2006
-
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 30]
-
-
-
+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-INTERNET-DRAFT DSA Information in the DNS
-OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
- DSA Keying and Signature Information in the DNS
- --- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
- The standard method of encoding US Government Digital Signature
- Algorithm keying and signature information for use in the Domain Name
- System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DSA Keying Information..................................3
- 3. DSA Signature Information...............................4
- 4. Performance Considerations..............................4
- 5. Security Considerations.................................5
- 6. IANA Considerations.....................................5
- Copyright, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative References.....................................7
-
- Author's Address...........................................8
- Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additional work is underway which would
- require the storage of keying and signature information in the DNS.
-
- This document describes how to encode US Government Digital Signature
- Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
- US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
- When DSA public keys are stored in the DNS, the structure of the
- relevant part of the RDATA part of the RR being used is the fields
- listed below in the order given.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- Field Size
- ----- ----
- T 1 octet
- Q 20 octets
- P 64 + T*8 octets
- G 64 + T*8 octets
- Y 64 + T*8 octets
-
- As described in [FIPS 186-2] and [Schneier], T is a key size
- parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
- is greater than 8 is reserved and the remainder of the data may have
- a different format in that case.) Q is a prime number selected at
- key generation time such that 2**159 < Q < 2**160. Thus Q is always
- 20 octets long and, as with all other fields, is stored in "big-
- endian" network order. P, G, and Y are calculated as directed by the
- [FIPS 186-2] key generation algorithm [Schneier]. P is in the range
- 2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
- and Y are quantities modulo P and so can be up to the same length as
- P and are allocated fixed size fields with the same number of octets
- as P.
-
- During the key generation process, a random number X must be
- generated such that 1 <= X <= Q-1. X is the private key and is used
- in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
- The portion of the RDATA area used for US Digital Signature Algorithm
- signature information is shown below with fields in the order they
- are listed and the contents of each multi-octet field in "big-endian"
- network order.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- First, the data signed must be determined. Then the following steps
- are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
- specified in the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate a random K such that 0 < K < Q.
-
- R = ( G**K mod P ) mod Q
-
- S = ( K**(-1) * (hash + X*R) ) mod Q
-
- For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
- 3174].
-
- Since Q is 160 bits long, R and S can not be larger than 20 octets,
- which is the space allocated.
-
- T is copied from the public key. It is not logically necessary in
- the SIG but is present so that values of T > 8 can more conveniently
- be used as an escape for extended versions of DSA or other algorithms
- as later standardized.
-
-
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA [RFC
- 3110] and DSA. With sufficient pre-computation, signature generation
- with DSA is faster than RSA. Key generation is also faster for DSA.
- However, signature verification is an order of magnitude slower than
- RSA when the RSA public exponent is chosen to be small, as is
- recommended for some applications.
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying and/or signature
- inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
- current DSA standard may limit the security of DSA. For particular
- applications, implementors are encouraged to consider the range of
- available algorithms and key sizes.
-
- DSA assumes the ability to frequently generate high quality random
- numbers. See [random] for guidance. DSA is designed so that if
- biased rather than random numbers are used, high bandwidth covert
- channels are possible. See [Schneier] and more recent research. The
- leakage of an entire DSA private key in only two DSA signatures has
- been demonstrated. DSA provides security only if trusted
- implementations, including trusted random number generation, are
- used.
-
-
-
-6. IANA Considerations
-
- Allocation of meaning to values of the T parameter that are not
- defined herein (i.e., > 8 ) requires an IETF standards actions. It
- is intended that values unallocated herein be used to cover future
- extensions of the DSS standard.
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Normative References
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, 27 January 2000.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative References
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, 11/01/1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, 11/01/1987.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS)", D. Eastlake 3rd. May 2001.
-
- [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
- Jones, September 2001.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [Schneier] - "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C" (second edition), Bruce Schneier,
- 1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Labortories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554(w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2006.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: September 2006 March 2006
-
-
-
-
- Storage of Diffie-Hellman Keying Information in the DNS
- ------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
-
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for encoding Diffie-Hellman keys in the Domain
- Name System is specified.
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
- Part of the format for Diffie-Hellman keys and the description
- thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
- and Hemma Prafullchandra. In addition, the following persons
- provided useful comments that were incorporated into the predecessor
- of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 1.1 About This Document....................................3
- 1.2 About Diffie-Hellman...................................3
- 2. Encoding Diffie-Hellman Keying Information..............4
- 3. Performance Considerations..............................5
- 4. IANA Considerations.....................................5
- 5. Security Considerations.................................5
- Copyright, Disclaimer, and Additional IPR Provisions.......5
-
- Normative References.......................................7
- Informative Refences.......................................7
-
- Author's Address...........................................8
- Expiration and File Name...................................8
-
- Appendix A: Well known prime/generator pairs...............9
- A.1. Well-Known Group 1: A 768 bit prime..................9
- A.2. Well-Known Group 2: A 1024 bit prime.................9
- A.3. Well-Known Group 3: A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- similar information [RFC 1034, 1035]. The DNS has been extended to
- include digital signatures and cryptographic keys as described in
- [RFC 4033, 4034, 4035] and additonal work is underway which would use
- the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
- This document describes how to store Diffie-Hellman keys in the DNS.
- Familiarity with the Diffie-Hellman key exchange algorithm is assumed
- [Schneier, RFC 2631].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119.
-
-
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Thus Diffie-
- Hellman is inherently a key agreement algorithm. As a result, no
- format is defined for Diffie-Hellman "signature information". For
- example, assume that two parties have local secrets "i" and "j".
- Assume they each respectively calculate X and Y as follows:
-
- X = g**i ( mod p )
-
- Y = g**j ( mod p )
-
- They exchange these quantities and then each calculates a Z as
- follows:
-
- Zi = Y**i ( mod p )
-
- Zj = X**j ( mod p )
-
- Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
- secret between the two parties that an adversary who does not know i
- or j will not be able to learn from the exchanged messages (unless
- the adversary can derive i or j by performing a discrete logarithm
- mod p which is hard for strong p and g).
-
- The private key for each party is their secret i (or j). The public
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- key is the pair p and g, which is the same for both parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
- in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
- When Diffie-Hellman keys appear within the RDATA portion of a RR,
- they are encoded as shown below.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR such as RRSIG which signs
- and authenticates the RR containing the keying information.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | KEY flags | protocol | algorithm=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | prime length (or flag) | prime (p) (or special) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / prime (p) (variable length) | generator length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | generator (g) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | public value length | public value (variable length)/
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / public value (g^i mod p) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Prime length is the length of the Diffie-Hellman prime (p) in bytes
- if it is 16 or greater. Prime contains the binary representation of
- the Diffie-Hellman prime with most significant byte first (i.e., in
- network order). If "prime length" field is 1 or 2, then the "prime"
- field is actually an unsigned index into a table of 65,536
- prime/generator pairs and the generator length SHOULD be zero. See
- Appedix A for defined table entries and Section 4 for information on
- allocating additional table entries. The meaning of a zero or 3
- through 15 value for "prime length" is reserved.
-
- Generator length is the length of the generator (g) in bytes.
- Generator is the binary representation of generator with most
- significant byte first. PublicValueLen is the Length of the Public
- Value (g**i (mod p)) in bytes. PublicValue is the binary
- representation of the DH public value with most significant byte
- first.
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient. But
- it is still advisable at this time to make reasonable efforts to
- minimize the size of RR sets containing keying information consistent
- with adequate security.
-
-
-
-4. IANA Considerations
-
- Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
- an IETF consensus as defined in [RFC 2434].
-
- Well known prime/generator pairs number 0x0000 through 0x07FF can
- only be assigned by an IETF standards action. [RFC 2539], the
- Proposed Standard predecessor of this document, assigned 0x0001
- through 0x0002. This document additionally assigns 0x0003. Pairs
- number 0s0800 through 0xBFFF can be assigned based on RFC
- documentation. Pairs number 0xC000 through 0xFFFF are available for
- private use and are not centrally coordinated. Use of such private
- pairs outside of a closed environment may result in conflicts and/or
- security failures.
-
-
-
-5. Security Considerations
-
- Keying information retrieved from the DNS should not be trusted
- unless (1) it has been securely obtained from a secure resolver or
- independently verified by the user and (2) this secure resolver and
- secure obtainment or independent verification conform to security
- policies acceptable to the user. As with all cryptographic
- algorithms, evaluating the necessary strength of the key is important
- and dependent on security policy.
-
- In addition, the usual Diffie-Hellman key strength considerations
- apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
- SHOULD be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright, Disclaimer, and Additional IPR Provisions
-
- Copyright (C) The Internet Society (2006). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Normative References
-
- [RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
- in RFCs", T. Narten, H. Alvestrand, October 1998.
-
- [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
- 1999.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Informative Refences
-
- [RFC 1034] - "Domain names - concepts and facilities", P.
- Mockapetris, November 1987.
-
- [RFC 1035] - "Domain names - implementation and specification", P.
- Mockapetris, November 1987.
-
- [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
- [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
- 1999.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
- and Sons.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in September 2006.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
- These numbers are copied from the IPSEC effort where the derivation
- of these values is more fully explained and additional information is
- available. Richard Schroeppel performed all the mathematical and
- computational work for this appendix.
-
-
-
-A.1. Well-Known Group 1: A 768 bit prime
-
- The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
- decimal value is
- 155251809230070893513091813125848175563133404943451431320235
- 119490296623994910210725866945387659164244291000768028886422
- 915080371891804634263272761303128298374438082089019628850917
- 0691316593175367469551763119843371637221007210577919
-
- Prime modulus: Length (32 bit words): 24, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2: A 1024 bit prime
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its decimal value is
- 179769313486231590770839156793787453197860296048756011706444
- 423684197180216158519368947833795864925541502180565485980503
- 646440548199239100050792877003355816639229553136239076508735
- 759914822574862575007425302077447712589550957937778424442426
- 617334727629299387668709205606050270810842907692932019128194
- 467627007
-
- Prime modulus: Length (32 bit words): 32, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
- FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3: A 1536 bit prime
-
- The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
- Its decimal value is
- 241031242692103258855207602219756607485695054850245994265411
- 694195810883168261222889009385826134161467322714147790401219
- 650364895705058263194273070680500922306273474534107340669624
- 601458936165977404102716924945320037872943417032584377865919
- 814376319377685986952408894019557734611984354530154704374720
- 774996976375008430892633929555996888245787241299381012913029
- 459299994792636526405928464720973038494721168143446471443848
- 8520940127459844288859336526896320919633919
-
- Prime modulus Length (32 bit words): 48, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
- C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
- 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
- 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Paul Vixie, ISC
-INTERNET-DRAFT
-<draft-ietf-dnsext-rfc2671bis-edns0-01.txt> March 17, 2008
-
-Intended Status: Standards Track
-Obsoletes: 2671 (if approved)
-
-
- Revised extension mechanisms for DNS (EDNS0)
-
-
-Status of this Memo
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
- Copyright (C) The IETF Trust (2007).
-
-
- Abstract
-
- The Domain Name System's wire protocol includes a number of fixed
- fields whose range has been or soon will be exhausted and does not
- allow clients to advertise their capabilities to servers. This
- document describes backward compatible mechanisms for allowing the
- protocol to grow.
-
-
-
-Expires September 2008 [Page 1]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-1 - Introduction
-
-1.1. DNS (see [RFC1035]) specifies a Message Format and within such
-messages there are standard formats for encoding options, errors, and
-name compression. The maximum allowable size of a DNS Message is fixed.
-Many of DNS's protocol limits are too small for uses which are or which
-are desired to become common. There is no way for implementations to
-advertise their capabilities.
-
-1.2. Unextended agents will not know how to interpret the protocol
-extensions detailed here. In practice, these clients will be upgraded
-when they have need of a new feature, and only new features will make
-use of the extensions. Extended agents must be prepared for behaviour
-of unextended clients in the face of new protocol elements, and fall
-back gracefully to unextended DNS. RFC 2671 originally has proposed
-extensions to the basic DNS protocol to overcome these deficiencies.
-This memo refines that specification and obsoletes RFC 2671.
-
-1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119 [RFC2119].
-
-2 - Affected Protocol Elements
-
-2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
-word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
-1-bit flags. The original reserved Z bits have been allocated to
-various purposes, and most of the RCODE values are now in use. More
-flags and more possible RCODEs are needed. The OPT pseudo-RR specified
-in Section 4 contains subfields that carry a bit field extension of the
-RCODE field and additional flag bits, respectively; for details see
-Section 4.6 below.
-
-2.2. The first two bits of a wire format domain label are used to denote
-the type of the label. [RFC1035 4.1.4] allocates two of the four
-possible types and reserves the other two. Proposals for use of the
-remaining types far outnumber those available. More label types were
-needed, and an extension mechanism was proposed in RFC 2671 [RFC2671
-Section 3]. Section 3 of this document reserves DNS labels with a first
-octet in the range of 64-127 decimal (label type 01) for future
-standardization of Extended DNS Labels.
-
-
-
-
-
-
-
-Expires September 2008 [Page 2]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
-While the minimum maximum reassembly buffer size still allows a limit of
-512 octets of UDP payload, most of the hosts now connected to the
-Internet are able to reassemble larger datagrams. Some mechanism must
-be created to allow requestors to advertise larger buffer sizes to
-responders. To this end, the OPT pseudo-RR specified in Section 4
-contains a maximum payload size field; for details see Section 4.5
-below.
-
-3 - Extended Label Types
-
-The first octet in the on-the-wire representation of a DNS label
-specifies the label type; the basic DNS specification [RFC1035]
-dedicates the two most significant bits of that octet for this purpose.
-
-This document reserves DNS label type 0b01 for use as an indication for
-Extended Label Types. A specific extended label type is selected by the
-6 least significant bits of the first octet. Thus, Extended Label Types
-are indicated by the values 64-127 (0b01xxxxxx) in the first octet of
-the label.
-
-Allocations from this range are to be made for IETF documents fully
-describing the syntax and semantics as well as the applicability of the
-particular Extended Label Type.
-
-This document does not describe any specific Extended Label Type.
-
-4 - OPT pseudo-RR
-
-4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional data
-section of a request, and to responses to such requests. An OPT is
-called a pseudo-RR because it pertains to a particular transport level
-message and not to any actual DNS data. OPT RRs MUST NOT be cached,
-forwarded, or stored in or loaded from master files. The quantity of
-OPT pseudo-RRs per message MUST be either zero or one, but not greater.
-
-4.2. An OPT RR has a fixed part and a variable set of options expressed
-as {attribute, value} pairs. The fixed part holds some DNS meta data
-and also a small collection of new protocol elements which we expect to
-be so popular that it would be a waste of wire space to encode them as
-{attribute, value} pairs.
-
-
-
-
-
-
-
-Expires September 2008 [Page 3]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-4.3. The fixed part of an OPT RR is structured as follows:
-
-Field Name Field Type Description
-------------------------------------------------------
-NAME domain name empty (root domain)
-TYPE u_int16_t OPT (41)
-CLASS u_int16_t sender's UDP payload size
-TTL u_int32_t extended RCODE and flags
-RDLEN u_int16_t describes RDATA
-RDATA octet stream {attribute,value} pairs
-
-
-4.4. The variable part of an OPT RR is encoded in its RDATA and is
-structured as zero or more of the following:
-
- : +0 (MSB) : +1 (LSB) :
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 0: | OPTION-CODE |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 2: | OPTION-LENGTH |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 4: | |
- / OPTION-DATA /
- / /
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-OPTION-CODE (Assigned by IANA.)
-
-OPTION-LENGTH Size (in octets) of OPTION-DATA.
-
-OPTION-DATA Varies per OPTION-CODE.
-
-4.4.1. Order of appearance of option tuples is never relevant. Any
-option whose meaning is affected by other options is so affected no
-matter which one comes first in the OPT RDATA.
-
-4.4.2. Any OPTION-CODE values not understood by a responder or requestor
-MUST be ignored. So, specifications of such options might wish to
-include some kind of signalled acknowledgement. For example, an option
-specification might say that if a responder sees option XYZ, it SHOULD
-include option XYZ in its response.
-
-
-
-
-
-
-Expires September 2008 [Page 4]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
-field) is the number of octets of the largest UDP payload that can be
-reassembled and delivered in the sender's network stack. Note that path
-MTU, with or without fragmentation, may be smaller than this. Values
-lower than 512 are undefined, and may be treated as format errors, or
-may be treated as equal to 512, at the implementor's discretion.
-
-4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
-reassembly buffer. Choosing 1280 on an Ethernet connected requestor
-would be reasonable. The consequence of choosing too large a value may
-be an ICMP message from an intermediate gateway, or even a silent drop
-of the response message.
-
-4.5.2. Both requestors and responders are advised to take account of the
-path's discovered MTU (if already known) when considering message sizes.
-
-4.5.3. The requestor's maximum payload size can change over time, and
-therefore MUST NOT be cached for use beyond the transaction in which it
-is advertised.
-
-4.5.4. The responder's maximum payload size can change over time, but
-can be reasonably expected to remain constant between two sequential
-transactions; for example, a meaningless QUERY to discover a responder's
-maximum UDP payload size, followed immediately by an UPDATE which takes
-advantage of this size. (This is considered preferrable to the outright
-use of TCP for oversized requests, if there is any reason to suspect
-that the responder implements EDNS, and if a request will not fit in the
-default 512 payload size limit.)
-
-4.5.5. Due to transaction overhead, it is unwise to advertise an
-architectural limit as a maximum UDP payload size. Just because your
-stack can reassemble 64KB datagrams, don't assume that you want to spend
-more than about 4KB of state memory per ongoing transaction.
-
-4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
-are structured as follows:
-
- : +0 (MSB) : +1 (LSB) :
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 0: | EXTENDED-RCODE | VERSION |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 2: | DO| Z |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
-
-
-
-Expires September 2008 [Page 5]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that
- EXTENDED-RCODE value zero (0) indicates that an
- unextended RCODE is in use (values zero (0) through
- fifteen (15)).
-
-VERSION Indicates the implementation level of whoever sets it.
- Full conformance with this specification is indicated by
- version zero (0). Requestors are encouraged to set this
- to the lowest implemented level capable of expressing a
- transaction, to minimize the responder and network load
- of discovering the greatest common implementation level
- between requestor and responder. A requestor's version
- numbering strategy should ideally be a run time
- configuration option.
-
- If a responder does not implement the VERSION level of
- the request, then it answers with RCODE=BADVERS. All
- responses MUST be limited in format to the VERSION level
- of the request, but the VERSION of each response MUST be
- the highest implementation level of the responder. In
- this way a requestor will learn the implementation level
- of a responder as a side effect of every response,
- including error responses, including RCODE=BADVERS.
-
-DO DNSSEC OK bit [RFC3225].
-
-Z Set to zero by senders and ignored by receivers, unless
- modified in a subsequent specification [IANAFLAGS].
-
-5 - Transport Considerations
-
-5.1. The presence of an OPT pseudo-RR in a request is an indication that
-the requestor fully implements the given version of EDNS, and can
-correctly understand any response that conforms to that feature's
-specification.
-
-5.2. Lack of use of these features in a request is an indication that
-the requestor does not implement any part of this specification and that
-the responder SHOULD NOT use any protocol extension described here in
-its response.
-
-5.3. Responders who do not understand these protocol extensions are
-expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL, or
-to appear to "time out" due to inappropriate action by a "middle box"
-such as a NAT, or to ignore extensions and respond only to unextended
-
-
-
-Expires September 2008 [Page 6]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-protocol elements. Therefore use of extensions SHOULD be "probed" such
-that a responder who isn't known to support them be allowed a retry with
-no extensions if it responds with such an RCODE, or does not respond.
-If a responder's capability level is cached by a requestor, a new probe
-SHOULD be sent periodically to test for changes to responder capability.
-
-5.4. If EDNS is used in a request, and the response arrives with TC set
-and with no EDNS OPT RR, a requestor should assume that truncation
-prevented the OPT RR from being appended by the responder, and further,
-that EDNS is not used in the response. Correspondingly, an EDNS
-responder who cannot fit all necessary elements (including an OPT RR)
-into a response, should respond with a normal (unextended) DNS response,
-possibly setting TC if the response will not fit in the unextended
-response message's 512-octet size.
-
-6 - Security Considerations
-
-Requestor-side specification of the maximum buffer size may open a new
-DNS denial of service attack if responders can be made to send messages
-which are too large for intermediate gateways to forward, thus leading
-to potential ICMP storms between gateways and responders.
-
-7 - IANA Considerations
-
-IANA has allocated RR type code 41 for OPT.
-
-This document controls the following IANA sub-registries in registry
-"DOMAIN NAME SYSTEM PARAMETERS":
-
- "EDNS Extended Label Type"
- "EDNS Option Codes"
- "EDNS Version Numbers"
- "Domain System Response Code"
-
-IANA is advised to re-parent these subregistries to this document.
-
-This document assigns label type 0b01xxxxxx as "EDNS Extended Label
-Type." We request that IANA record this assignment.
-
-This document assigns option code 65535 to "Reserved for future
-expansion."
-
-This document assigns EDNS Extended RCODE "16" to "BADVERS".
-
-
-
-
-
-Expires September 2008 [Page 7]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-IESG approval is required to create new entries in the EDNS Extended
-Label Type or EDNS Version Number registries, while any published RFC
-(including Informational, Experimental, or BCP) is grounds for
-allocation of an EDNS Option Code.
-
-8 - Acknowledgements
-
-Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
-Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Thomas Narten,
-Alfred Hoenes and Markku Savela were each instrumental in creating and
-refining this specification.
-
-9 - References
-
-[RFC1035] P. Mockapetris, "Domain Names - Implementation and
- Specification," RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels," RFC 2119, Harvard University, March
- 1997.
-
-[RFC2671] P. Vixie, "Extension mechanisms for DNS (EDNS0)," RFC 2671,
- Internet Software Consortium, August 1999.
-
-[RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC," RFC
- 3225, Nominum Inc., December 2001.
-
-[IANAFLAGS] IANA, "DNS Header Flags and EDNS Header Flags," web site
- http://www.iana.org/assignments/dns-header-flags, as of
- June 2005 or later.
-
-10 - Author's Address
-
-Paul Vixie
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 423 1301
- EMail: vixie@isc.org
-
-
-
-
-
-
-
-
-Expires September 2008 [Page 8]
-\f
-INTERNET-DRAFT EDNS0 March 2008
-
-
-Full Copyright Statement
-
-Copyright (C) IETF Trust (2007).
-
-This document is subject to the rights, licenses and restrictions
-contained in BCP 78, and except as set forth therein, the authors retain
-all their rights.
-
-This document and the information contained herein are provided on an
-"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
-IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE
-INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
-WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
-The IETF takes no position regarding the validity or scope of any
-Intellectual Property Rights or other rights that might be claimed to
-pertain to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; nor does it represent that it has made any
-independent effort to identify any such rights. Information on the
-procedures with respect to rights in RFC documents can be found in BCP
-78 and BCP 79.
-
-Copies of IPR disclosures made to the IETF Secretariat and any
-assurances of licenses to be made available, or the result of an attempt
-made to obtain a general license or permission for the use of such
-proprietary rights by implementers or users of this specification can be
-obtained from the IETF on-line IPR repository at
-http://www.ietf.org/ipr.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-that may cover technology that may be required to implement this
-standard. Please address the information to the IETF at
-ietf-ipr@ietf.org.
-
-Acknowledgement
-
-Funding for the RFC Editor function is provided by the IETF
-Administrative Support Activity (IASA).
-
-
-
-
-Expires September 2008 [Page 9]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-Network Working Group 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
+++ /dev/null
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
-
+++ /dev/null
-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 $.
-
-
- 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
+++ /dev/null
-
-
-
-Network Working Group M. StJohns
-Internet-Draft Nominum, Inc.
-Intended status: Informational November 29, 2006
-Expires: June 2, 2007
-
-
- Automated Updates of DNSSEC Trust Anchors
- draft-ietf-dnsext-trustupdate-timers-05
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on June 2, 2007.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes a means for automated, authenticated and
- authorized updating of DNSSEC "trust anchors". The method provides
- protection against N-1 key compromises of N keys in the trust point
- key set. Based on the trust established by the presence of a current
- anchor, other anchors may be added at the same place in the
- hierarchy, and, ultimately, supplant the existing anchor(s).
-
- This mechanism will require changes to resolver management behavior
-
-
-
-StJohns Expires June 2, 2007 [Page 1]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- (but not resolver resolution behavior), and the addition of a single
- flag bit to the DNSKEY record.
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
- 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
- 2.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2. Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
- 2.3. Active Refresh . . . . . . . . . . . . . . . . . . . . . . 5
- 2.4. Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
- 2.4.1. Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
- 2.4.2. Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
- 2.4.3. Minimum Trust Anchors per Trust Point . . . . . . . . 6
- 3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
- 4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 4.1. Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 4.2. States . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 5. Trust Point Deletion . . . . . . . . . . . . . . . . . . . . . 8
- 6. Scenarios - Informative . . . . . . . . . . . . . . . . . . . 9
- 6.1. Adding a Trust Anchor . . . . . . . . . . . . . . . . . . 9
- 6.2. Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
- 6.3. Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 10
- 6.4. Active Key Compromised . . . . . . . . . . . . . . . . . . 10
- 6.5. Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
- 6.6. Trust Point Deletion . . . . . . . . . . . . . . . . . . . 10
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 8.1. Key Ownership vs Acceptance Policy . . . . . . . . . . . . 11
- 8.2. Multiple Key Compromise . . . . . . . . . . . . . . . . . 11
- 8.3. Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 11
- 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
- Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
- Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 2]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-1. Introduction
-
- As part of the reality of fielding DNSSEC (Domain Name System
- Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
- come to the realization that there will not be one signed name space,
- but rather islands of signed name space each originating from
- specific points (i.e. 'trust points') in the DNS tree. Each of those
- islands will be identified by the trust point name, and validated by
- at least one associated public key. For the purpose of this document
- we'll call the association of that name and a particular key a 'trust
- anchor'. A particular trust point can have more than one key
- designated as a trust anchor.
-
- For a DNSSEC-aware resolver to validate information in a DNSSEC
- protected branch of the hierarchy, it must have knowledge of a trust
- anchor applicable to that branch. It may also have more than one
- trust anchor for any given trust point. Under current rules, a chain
- of trust for DNSSEC-protected data that chains its way back to ANY
- known trust anchor is considered 'secure'.
-
- Because of the probable balkanization of the DNSSEC tree due to
- signing voids at key locations, a resolver may need to know literally
- thousands of trust anchors to perform its duties. (e.g. Consider an
- unsigned ".COM".) Requiring the owner of the resolver to manually
- manage this many relationships is problematic. It's even more
- problematic when considering the eventual requirement for key
- replacement/update for a given trust anchor. The mechanism described
- herein won't help with the initial configuration of the trust anchors
- in the resolvers, but should make trust point key replacement/
- rollover more viable.
-
- As mentioned above, this document describes a mechanism whereby a
- resolver can update the trust anchors for a given trust point, mainly
- without human intervention at the resolver. There are some corner
- cases discussed (e.g. multiple key compromise) that may require
- manual intervention, but they should be few and far between. This
- document DOES NOT discuss the general problem of the initial
- configuration of trust anchors for the resolver.
-
-1.1. Compliance Nomenclature
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14, [RFC2119].
-
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 3]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-2. Theory of Operation
-
- The general concept of this mechanism is that existing trust anchors
- can be used to authenticate new trust anchors at the same point in
- the DNS hierarchy. When a zone operator adds a new SEP key (i.e. a
- DNSKEY with the Secure Entry Point bit set) (see [RFC4034]section
- 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
- validated by an existing trust anchor, then the resolver can add the
- new key to its valid set of trust anchors for that trust point.
-
- There are some issues with this approach which need to be mitigated.
- For example, a compromise of one of the existing keys could allow an
- attacker to add their own 'valid' data. This implies a need for a
- method to revoke an existing key regardless of whether or not that
- key is compromised. As another example, assuming a single key
- compromise, we need to prevent an attacker from adding a new key and
- revoking all the other old keys.
-
-2.1. Revocation
-
- Assume two trust anchor keys A and B. Assume that B has been
- compromised. Without a specific revocation bit, B could invalidate A
- simply by sending out a signed trust point key set which didn't
- contain A. To fix this, we add a mechanism which requires knowledge
- of the private key of a DNSKEY to revoke that DNSKEY.
-
- A key is considered revoked when the resolver sees the key in a self-
- signed RRSet and the key has the REVOKE bit (see Section 7 below) set
- to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this
- key as a trust anchor or for any other purposes except validating the
- RRSIG it signed over the DNSKEY RRSet specifically for the purpose of
- validating the revocation. Unlike the 'Add' operation below,
- revocation is immediate and permanent upon receipt of a valid
- revocation at the resolver.
-
- A self-signed RRSet is a DNSKEY RRSet which contains the specific
- DNSKEY and for which there is a corresponding validated RRSIG record.
- It's not a special DNSKEY RRSet, just a way of describing the
- validation requirements for that RRSet.
-
- N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
- than one without the bit set. This affects the matching of a DNSKEY
- to DS records in the parent, or the fingerprint stored at a resolver
- used to configure a trust point.
-
- In the given example, the attacker could revoke B because it has
- knowledge of B's private key, but could not revoke A.
-
-
-
-
-StJohns Expires June 2, 2007 [Page 4]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-2.2. Add Hold-Down
-
- Assume two trust point keys A and B. Assume that B has been
- compromised. An attacker could generate and add a new trust anchor
- key - C (by adding C to the DNSKEY RRSet and signing it with B), and
- then invalidate the compromised key. This would result in both the
- attacker and owner being able to sign data in the zone and have it
- accepted as valid by resolvers.
-
- To mitigate but not completely solve this problem, we add a hold-down
- time to the addition of the trust anchor. When the resolver sees a
- new SEP key in a validated trust point DNSKEY RRSet, the resolver
- starts an acceptance timer, and remembers all the keys that validated
- the RRSet. If the resolver ever sees the DNSKEY RRSet without the
- new key but validly signed, it stops the acceptance process for that
- key and resets the acceptance timer. If all of the keys which were
- originally used to validate this key are revoked prior to the timer
- expiring, the resolver stops the acceptance process and resets the
- timer.
-
- Once the timer expires, the new key will be added as a trust anchor
- the next time the validated RRSet with the new key is seen at the
- resolver. The resolver MUST NOT treat the new key as a trust anchor
- until the hold down time expires AND it has retrieved and validated a
- DNSKEY RRSet after the hold down time which contains the new key.
-
- N.B.: Once the resolver has accepted a key as a trust anchor, the key
- MUST be considered a valid trust anchor by that resolver until
- explictly revoked as described above.
-
- In the given example, the zone owner can recover from a compromise by
- revoking B and adding a new key D and signing the DNSKEY RRSet with
- both A and B.
-
- The reason this does not completely solve the problem has to do with
- the distributed nature of DNS. The resolver only knows what it sees.
- A determined attacker who holds one compromised key could keep a
- single resolver from realizing that key had been compromised by
- intercepting 'real' data from the originating zone and substituting
- their own (e.g. using the example, signed only by B). This is no
- worse than the current situation assuming a compromised key.
-
-2.3. Active Refresh
-
- A resolver which has been configured for automatic update of keys
- from a particular trust point MUST query that trust point (e.g. do a
- lookup for the DNSKEY RRSet and related RRSIG records) no less often
- than the lesser of 15 days or half the original TTL for the DNSKEY
-
-
-
-StJohns Expires June 2, 2007 [Page 5]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- RRSet or half the RRSIG expiration interval and no more often than
- once per hour. The expiration interval is the amount of time from
- when the RRSIG was last retrieved until the expiration time in the
- RRSIG.
-
- If the query fails, the resolver MUST repeat the query until
- satisfied no more often than once an hour and no less often than the
- lesser of 1 day or 10% of the original TTL or 10% of the original
- expiration interval. I.e.: retryTime = MAX (1 hour, MIN (1 day, .1 *
- origTTL, .1 * expireInterval)).
-
-2.4. Resolver Parameters
-
-2.4.1. Add Hold-Down Time
-
- The add hold-down time is 30 days or the expiration time of the
- original TTL of the first trust point DNSKEY RRSet which contained
- the new key, whichever is greater. This ensures that at least two
- validated DNSKEY RRSets which contain the new key MUST be seen by the
- resolver prior to the key's acceptance.
-
-2.4.2. Remove Hold-Down Time
-
- The remove hold-down time is 30 days. This parameter is solely a key
- management database bookeeping parameter. Failure to remove
- information about the state of defunct keys from the database will
- not adversely impact the security of this protocol, but may end up
- with a database cluttered with obsolete key information.
-
-2.4.3. Minimum Trust Anchors per Trust Point
-
- A compliant resolver MUST be able to manage at least five SEP keys
- per trust point.
-
-
-3. Changes to DNSKEY RDATA Wire Format
-
- Bit n [msj2]of the DNSKEY Flags field is designated as the 'REVOKE'
- flag. If this bit is set to '1', AND the resolver sees an
- RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
- consider this key permanently invalid for all purposes except for
- validating the revocation.
-
-
-4. State Table
-
- The most important thing to understand is the resolver's view of any
- key at a trust point. The following state table describes that view
-
-
-
-StJohns Expires June 2, 2007 [Page 6]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- at various points in the key's lifetime. The table is a normative
- part of this specification. The initial state of the key is 'Start'.
- The resolver's view of the state of the key changes as various events
- occur.
-
- This is the state of a trust point key as seen from the resolver.
- The column on the left indicates the current state. The header at
- the top shows the next state. The intersection of the two shows the
- event that will cause the state to transition from the current state
- to the next.
-
-
- NEXT STATE
- --------------------------------------------------
- FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
- ----------------------------------------------------------
- Start | |NewKey | | | | |
- ----------------------------------------------------------
- AddPend |KeyRem | |AddTime| | |
- ----------------------------------------------------------
- Valid | | | |KeyRem |Revbit | |
- ----------------------------------------------------------
- Missing | | |KeyPres| |Revbit | |
- ----------------------------------------------------------
- Revoked | | | | | |RemTime|
- ----------------------------------------------------------
- Removed | | | | | | |
- ----------------------------------------------------------
-
-
- State Table
-
-4.1. Events
- NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
- That key will become a new trust anchor for the named trust point
- after it's been present in the RRSet for at least 'add time'.
- KeyPres The key has returned to the valid DNSKEY RRSet.
- KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
- this key.
- AddTime The key has been in every valid DNSKEY RRSet seen for at
- least the 'add time'.
- RemTime A revoked key has been missing from the trust point DNSKEY
- RRSet for sufficient time to be removed from the trust set.
- RevBit The key has appeared in the trust anchor DNSKEY RRSet with
- its "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
- signed by this key.
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 7]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-4.2. States
- Start The key doesn't yet exist as a trust anchor at the resolver.
- It may or may not exist at the zone server, but either hasn't yet
- been seen at the resolver or was seen but was absent from the last
- DNSKEY RRSet (e.g. KeyRem event).
- AddPend The key has been seen at the resolver, has its 'SEP' bit
- set, and has been included in a validated DNSKEY RRSet. There is
- a hold-down time for the key before it can be used as a trust
- anchor.
- Valid The key has been seen at the resolver and has been included in
- all validated DNSKEY RRSets from the time it was first seen up
- through the hold-down time. It is now valid for verifying RRSets
- that arrive after the hold down time. Clarification: The DNSKEY
- RRSet does not need to be continuously present at the resolver
- (e.g. its TTL might expire). If the RRSet is seen, and is
- validated (i.e. verifies against an existing trust anchor), this
- key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
- Missing This is an abnormal state. The key remains as a valid trust
- point key, but was not seen at the resolver in the last validated
- DNSKEY RRSet. This is an abnormal state because the zone operator
- should be using the REVOKE bit prior to removal.
- Revoked This is the state a key moves to once the resolver sees an
- RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
- this key with its REVOKE bit set to '1'. Once in this state, this
- key MUST permanently be considered invalid as a trust anchor.
- Removed After a fairly long hold-down time, information about this
- key may be purged from the resolver. A key in the removed state
- MUST NOT be considered a valid trust anchor. (Note: this state is
- more or less equivalent to the "Start" state, except that it's bad
- practice to re-introduce previously used keys - think of this as
- the holding state for all the old keys for which the resolver no
- longer needs to track state.)
-
-
-5. Trust Point Deletion
-
- A trust point which has all of its trust anchors revoked is
- considered deleted and is treated as if the trust point was never
- configured. If there are no superior configured trust points, data
- at and below the deleted trust point are considered insecure by the
- resolver. If there ARE superior configured trust points, data at and
- below the deleted trust point are evaluated with respect to the
- superior trust point(s).
-
- Alternately, a trust point which is subordinate to another configured
- trust point MAY be deleted by a resolver after 180 days where such
- subordinate trust point validly chains to a superior trust point.
- The decision to delete the subordinate trust anchor is a local
-
-
-
-StJohns Expires June 2, 2007 [Page 8]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- configuration decision. Once the subordinate trust point is deleted,
- validation of the subordinate zone is dependent on validating the
- chain of trust to the superior trust point.
-
-
-6. Scenarios - Informative
-
- The suggested model for operation is to have one active key and one
- stand-by key at each trust point. The active key will be used to
- sign the DNSKEY RRSet. The stand-by key will not normally sign this
- RRSet, but the resolver will accept it as a trust anchor if/when it
- sees the signature on the trust point DNSKEY RRSet.
-
- Since the stand-by key is not in active signing use, the associated
- private key may (and should) be provided with additional protections
- not normally available to a key that must be used frequently. E.g.
- locked in a safe, split among many parties, etc. Notionally, the
- stand-by key should be less subject to compromise than an active key,
- but that will be dependent on operational concerns not addressed
- here.
-
-6.1. Adding a Trust Anchor
-
- Assume an existing trust anchor key 'A'.
- 1. Generate a new key pair.
- 2. Create a DNSKEY record from the key pair and set the SEP and Zone
- Key bits.
- 3. Add the DNSKEY to the RRSet.
- 4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
- 'A'.
- 5. Wait a while (i.e. for various resolvers timers to go off and for
- them to retrieve the new DNSKEY RRSet and signatures).
- 6. The new trust anchor will be populated at the resolvers on the
- schedule described by the state table and update algorithm - see
- Section 2 above
-
-6.2. Deleting a Trust Anchor
-
- Assume existing trust anchors 'A' and 'B' and that you want to revoke
- and delete 'A'.
- 1. Set the revocation bit on key 'A'.
- 2. Sign the DNSKEY RRSet with both 'A' and 'B'.
- 'A' is now revoked. The operator should include the revoked 'A' in
- the RRSet for at least the remove hold-down time, but then may remove
- it from the DNSKEY RRSet.
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 9]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-6.3. Key Roll-Over
-
- Assume existing keys A and B. 'A' is actively in use (i.e. has been
- signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has been
- in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
- used to sign the RRSet.)
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'A'.
- 4. Sign the RRSet with 'A' and 'B'.
- 'A' is now revoked, 'B' is now the active key, and 'C' will be the
- stand-by key once the hold-down expires. The operator should include
- the revoked 'A' in the RRSet for at least the remove hold-down time,
- but may then remove it from the DNSKEY RRSet.
-
-6.4. Active Key Compromised
-
- This is the same as the mechanism for Key Roll-Over (Section 6.3)
- above assuming 'A' is the active key.
-
-6.5. Stand-by Key Compromised
-
- Using the same assumptions and naming conventions as Key Roll-Over
- (Section 6.3) above:
- 1. Generate a new key pair 'C'.
- 2. Add 'C' to the DNSKEY RRSet.
- 3. Set the revocation bit on key 'B'.
- 4. Sign the RRSet with 'A' and 'B'.
- 'B' is now revoked, 'A' remains the active key, and 'C' will be the
- stand-by key once the hold-down expires. 'B' should continue to be
- included in the RRSet for the remove hold-down time.
-
-6.6. Trust Point Deletion
-
- To delete a trust point which is subordinate to another configured
- trust point (e.g. example.com to .com) requires some juggling of the
- data. The specific process is:
- 1. Generate a new DNSKEY and DS record and provide the DS record to
- the parent along with DS records for the old keys
- 2. Once the parent has published the DSs, add the new DNSKEY to the
- RRSet and revoke ALL of the old keys at the same time while
- signing the DNSKEY RRSet with all of the old and new keys.
- 3. After 30 days stop publishing the old, revoked keys and remove
- any corresponding DS records in the parent.
- Revoking the old trust point keys at the same time as adding new keys
- that chain to a superior trust prevents the resolver from adding the
- new keys as trust anchors. Adding DS records for the old keys avoids
- a race condition where either the subordinate zone becomes unsecure
-
-
-
-StJohns Expires June 2, 2007 [Page 10]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- (because the trust point was deleted) or becomes bogus (because it
- didn't chain to the superior zone).
-
-
-7. IANA Considerations
-
- The IANA will need to assign a bit in the DNSKEY flags field (see
- section 4.3 of [RFC3755]) for the REVOKE bit. There are no other
- IANA actions required.
-
-
-8. Security Considerations
-
- In addition to the following sections, see also Theory of Operation
- above and especially Section 2.2 for related discussions.
-
-8.1. Key Ownership vs Acceptance Policy
-
- The reader should note that, while the zone owner is responsible for
- creating and distributing keys, it's wholly the decision of the
- resolver owner as to whether to accept such keys for the
- authentication of the zone information. This implies the decision to
- update trust anchor keys based on trust for a current trust anchor
- key is also the resolver owner's decision.
-
- The resolver owner (and resolver implementers) MAY choose to permit
- or prevent key status updates based on this mechanism for specific
- trust points. If they choose to prevent the automated updates, they
- will need to establish a mechanism for manual or other out-of-band
- updates outside the scope of this document.
-
-8.2. Multiple Key Compromise
-
- This scheme permits recovery as long as at least one valid trust
- anchor key remains uncompromised. E.g. if there are three keys, you
- can recover if two of them are compromised. The zone owner should
- determine their own level of comfort with respect to the number of
- active valid trust anchors in a zone and should be prepared to
- implement recovery procedures once they detect a compromise. A
- manual or other out-of-band update of all resolvers will be required
- if all trust anchor keys at a trust point are compromised.
-
-8.3. Dynamic Updates
-
- Allowing a resolver to update its trust anchor set based on in-band
- key information is potentially less secure than a manual process.
- However, given the nature of the DNS, the number of resolvers that
- would require update if a trust anchor key were compromised, and the
-
-
-
-StJohns Expires June 2, 2007 [Page 11]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
- lack of a standard management framework for DNS, this approach is no
- worse than the existing situation.
-
-
-9. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer (DS)", RFC 3755, May 2004.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
-Editorial Comments
-
- [msj2] msj: To be assigned.
-
-
-Author's Address
-
- Michael StJohns
- Nominum, Inc.
- 2385 Bay Road
- Redwood City, CA 94063
- USA
-
- Phone: +1-301-528-4729
- Email: Mike.StJohns@nominum.com
- URI: www.nominum.com
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 12]
-\f
-Internet-Draft trustanchor-update November 2006
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is provided by the IETF
- Administrative Support Activity (IASA).
-
-
-
-
-
-StJohns Expires June 2, 2007 [Page 13]
-\f
-
+++ /dev/null
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
+++ /dev/null
-
-
-
-Network Working Group M. Andrews
-Internet-Draft ISC
-Intended status: BCP June 5, 2008
-Expires: December 7, 2008
-
-
- Locally-served DNS Zones
- draft-ietf-dnsop-default-local-zones-05
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on December 7, 2008.
-
-Abstract
-
- Experience has shown that there are a number of DNS zones all
- iterative resolvers and recursive nameservers should, unless
- configured otherwise, automatically serve. RFC 4193 specifies that
- this should occur for D.F.IP6.ARPA. This document extends the
- practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space
- and other well known zones with similar characteristics.
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 1]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Effects on sites using RFC 1918 addresses. . . . . . . . . . . 4
- 3. Changes to Iterative Resolver Behaviour. . . . . . . . . . . . 4
- 4. Lists Of Zones Covered . . . . . . . . . . . . . . . . . . . . 5
- 4.1. RFC 1918 Zones . . . . . . . . . . . . . . . . . . . . . . 5
- 4.2. RFC 3330 Zones . . . . . . . . . . . . . . . . . . . . . . 6
- 4.3. Local IPv6 Unicast Addresses . . . . . . . . . . . . . . . 6
- 4.4. IPv6 Locally Assigned Local Addresses . . . . . . . . . . 6
- 4.5. IPv6 Link Local Addresses . . . . . . . . . . . . . . . . 7
- 5. Zones that are Out-Of-Scope . . . . . . . . . . . . . . . . . 7
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
- Appendix A. Change History [To Be Removed on Publication] . . . . 10
- A.1. draft-ietf-dnsop-default-local-zones-05.txt . . . . . . . 10
- A.2. draft-ietf-dnsop-default-local-zones-04.txt . . . . . . . 10
- A.3. draft-ietf-dnsop-default-local-zones-03.txt . . . . . . . 10
- A.4. draft-ietf-dnsop-default-local-zones-02.txt . . . . . . . 10
- A.5. draft-ietf-dnsop-default-local-zones-01.txt . . . . . . . 11
- A.6. draft-ietf-dnsop-default-local-zones-00.txt . . . . . . . 11
- A.7. draft-andrews-full-service-resolvers-03.txt . . . . . . . 11
- A.8. draft-andrews-full-service-resolvers-02.txt . . . . . . . 11
- Appendix B. Proposed Status [To Be Removed on Publication] . . . 11
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
- Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 2]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-1. Introduction
-
- Experience has shown that there are a number of DNS [RFC 1034] [RFC
- 1035] zones that all iterative resolvers and recursive nameservers
- SHOULD, unless intentionally configured otherwise, automatically
- serve. These zones include, but are not limited to, the IN-ADDR.ARPA
- zones for the address space allocated by [RFC 1918] and the IP6.ARPA
- zones for locally assigned unique local IPv6 addresses, [RFC 4193].
-
- This recommendation is made because data has shown that significant
- leakage of queries for these name spaces is occurring, despite
- instructions to restrict them, and because it has therefore become
- necessary to deploy sacrificial name servers to protect the immediate
- parent name servers for these zones from excessive, unintentional,
- query load [AS112] [I-D.draft-ietf-dnsop-as112-ops]
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help]. There is every
- expectation that the query load will continue to increase unless
- steps are taken as outlined here.
-
- Additionally, queries from clients behind badly configured firewalls
- that allow outgoing queries for these name spaces but drop the
- responses, put a significant load on the root servers (forward but no
- reverse zones configured). They also cause operational load for the
- root server operators as they have to reply to enquiries about why
- the root servers are "attacking" these clients. Changing the default
- configuration will address all these issues for the zones listed in
- Section 4.
-
- [RFC 4193] recommends that queries for D.F.IP6.ARPA be handled
- locally. This document extends the recommendation to cover the IN-
- ADDR.ARPA zones for [RFC 1918] and other well known IN-ADDR.ARPA and
- IP6.ARPA zones for which queries should not appear on the public
- Internet.
-
- It is hoped that by doing this the number of sacrificial servers
- [AS112] will not have to be increased, and may in time be reduced.
-
- This recommendation should also help DNS responsiveness for sites
- which are using [RFC 1918] addresses but do not follow the last
- paragraph in Section 3 of [RFC 1918].
-
-1.1. Reserved Words
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 3]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-2. Effects on sites using RFC 1918 addresses.
-
- For most sites using [RFC 1918] addresses, the changes here will have
- little or no detrimental effect. If the site does not already have
- the reverse tree populated the only effect will be that the name
- error responses will be generated locally rather than remotely.
-
- For sites that do have the reverse tree populated, most will either
- have a local copy of the zones or will be forwarding the queries to
- servers which have local copies of the zone. Therefore this
- recommendation will not be relevant.
-
- The most significant impact will be felt at sites that make use of
- delegations for [RFC 1918] addresses and have populated these zones.
- These sites will need to override the default configuration expressed
- in this document to allow resolution to continue. Typically, such
- sites will be fully disconnected from the Internet and have their own
- root servers for their own non-Internet DNS tree.
-
-
-3. Changes to Iterative Resolver Behaviour.
-
- Unless configured otherwise, an iterative resolver will now return
- authoritatively (aa=1) name errors (RCODE=3) for queries within the
- zones in Section 4, with the obvious exception of queries for the
- zone name itself where SOA, NS and "no data" responses will be
- returned as appropriate to the query type. One common way to do this
- is to serve empty (SOA and NS only) zones.
-
- An implementation of this recommendation MUST provide a mechanism to
- disable this new behaviour, and SHOULD allow this decision on a zone
- by zone basis.
-
- If using empty zones one SHOULD NOT use the same NS and SOA records
- as used on the public Internet servers as that will make it harder to
- detect the origin of the responses and thus any leakage to the public
- Internet servers. This document recommends that the NS record
- defaults to the name of the zone and the SOA MNAME defaults to the
- name of the only NS RR's target. The SOA RNAME should default to
- "nobody.invalid." [RFC 2606]. Implementations SHOULD provide a
- mechanism to set these values. No address records need to be
- provided for the name server.
-
- Below is an example of a generic empty zone in master file format.
- It will produce a negative cache TTL of 3 hours.
-
- @ 10800 IN SOA @ nobody.invalid. 1 3600 1200 604800 10800
- @ 10800 IN NS @
-
-
-
-Andrews Expires December 7, 2008 [Page 4]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- The SOA RR is needed to support negative caching [RFC 2308] of name
- error responses and to point clients to the primary master for DNS
- dynamic updates.
-
- SOA values of particular importance are the MNAME, the SOA RR's TTL
- and the negTTL value. Both TTL values SHOULD match. The rest of the
- SOA timer values MAY be chosen arbitrarily since they are not
- intended to control any zone transfer activity.
-
- The NS RR is needed as some UPDATE [RFC 2136] clients use NS queries
- to discover the zone to be updated. Having no address records for
- the name server is expected to abort UPDATE processing in the client.
-
-
-4. Lists Of Zones Covered
-
- The following subsections are intended to seed the IANA registry as
- requested in the IANA Considerations Section. The zone name is the
- entity to be registered.
-
-4.1. RFC 1918 Zones
-
- The following zones correspond to the IPv4 address space reserved in
- [RFC 1918].
-
- +----------------------+
- | Zone |
- +----------------------+
- | 10.IN-ADDR.ARPA |
- | 16.172.IN-ADDR.ARPA |
- | 17.172.IN-ADDR.ARPA |
- | 18.172.IN-ADDR.ARPA |
- | 19.172.IN-ADDR.ARPA |
- | 20.172.IN-ADDR.ARPA |
- | 21.172.IN-ADDR.ARPA |
- | 22.172.IN-ADDR.ARPA |
- | 23.172.IN-ADDR.ARPA |
- | 24.172.IN-ADDR.ARPA |
- | 25.172.IN-ADDR.ARPA |
- | 26.172.IN-ADDR.ARPA |
- | 27.172.IN-ADDR.ARPA |
- | 28.172.IN-ADDR.ARPA |
- | 29.172.IN-ADDR.ARPA |
- | 30.172.IN-ADDR.ARPA |
- | 31.172.IN-ADDR.ARPA |
- | 168.192.IN-ADDR.ARPA |
- +----------------------+
-
-
-
-
-Andrews Expires December 7, 2008 [Page 5]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-4.2. RFC 3330 Zones
-
- The following zones correspond to those address ranges from [RFC
- 3330] that are not expected to appear as source or destination
- addresses on the public Internet and to not have a unique name to
- associate with.
-
- The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not a
- attempt to discourage any practice to provide a PTR RR for
- 1.0.0.127.IN-ADDR.ARPA locally. In fact, a meaningful reverse
- mapping should exist, but the exact setup is out of the scope of this
- document. Similar logic applies to the reverse mapping for ::1
- (Section 4.3). The recommendations made here simply assume no other
- coverage for these domains exists.
-
- +------------------------------+------------------------+
- | Zone | Description |
- +------------------------------+------------------------+
- | 0.IN-ADDR.ARPA | IPv4 "THIS" NETWORK |
- | 127.IN-ADDR.ARPA | IPv4 LOOP-BACK NETWORK |
- | 254.169.IN-ADDR.ARPA | IPv4 LINK LOCAL |
- | 2.0.192.IN-ADDR.ARPA | IPv4 TEST NET |
- | 255.255.255.255.IN-ADDR.ARPA | IPv4 BROADCAST |
- +------------------------------+------------------------+
-
-4.3. Local IPv6 Unicast Addresses
-
- The reverse mappings ([RFC 3596], Section 2.5 IP6.ARPA Domain) for
- the IPv6 Unspecified (::) and Loopback (::1) addresses ([RFC 4291],
- Sections 2.4, 2.5.2 and 2.5.3) are covered by these two zones:
-
- +-------------------------------------------+
- | Zone |
- +-------------------------------------------+
- | 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
- | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
- | 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.\ |
- | 0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA |
- +-------------------------------------------+
-
- Note: Line breaks and a escapes '\' have been inserted above for
- readability and to adhere to line width constraints. They are not
- parts of the zone names.
-
-4.4. IPv6 Locally Assigned Local Addresses
-
- Section 4.4 of [RFC 4193] already required special treatment of:
-
-
-
-
-Andrews Expires December 7, 2008 [Page 6]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- +--------------+
- | Zone |
- +--------------+
- | D.F.IP6.ARPA |
- +--------------+
-
-4.5. IPv6 Link Local Addresses
-
- IPv6 Link-Local Addresses as of [RFC 4291], Section 2.5.6 are covered
- by four distinct reverse DNS zones:
-
- +----------------+
- | Zone |
- +----------------+
- | 8.E.F.IP6.ARPA |
- | 9.E.F.IP6.ARPA |
- | A.E.F.IP6.ARPA |
- | B.E.F.IP6.ARPA |
- +----------------+
-
-
-5. Zones that are Out-Of-Scope
-
- IPv6 site-local addresses, [RFC 4291] Sections 2.4 and 2.5.7, and
- IPv6 Non-Locally Assigned Local addresses [RFC 4193] are not covered
- here. It is expected that IPv6 site-local addresses will be self
- correcting as IPv6 implementations remove support for site-local
- addresses. However, sacrificial servers for C.E.F.IP6.ARPA through
- F.E.F.IP6.ARPA may still need to be deployed in the short term if the
- traffic becomes excessive.
-
- For IPv6 Non-Locally Assigned Local addresses (L = 0) [RFC 4193],
- there has been no decision made about whether the Regional Internet
- Registries (RIRs) will provide delegations in this space or not. If
- they don't, then C.F.IP6.ARPA will need to be added to the list in
- Section 4.4. If they do, then registries will need to take steps to
- ensure that name servers are provided for these addresses.
-
- This document also ignores IP6.INT. IP6.INT has been wound up with
- only legacy resolvers now generating reverse queries under IP6.INT
- [RFC 4159].
-
- This document has also deliberately ignored names immediately under
- the root domain. While there is a subset of queries to the root name
- servers which could be addressed using the techniques described here
- (e.g. .local, .workgroup and IPv4 addresses), there is also a vast
- amount of traffic that requires a different strategy (e.g. lookups
- for unqualified hostnames, IPv6 addresses).
-
-
-
-Andrews Expires December 7, 2008 [Page 7]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-6. IANA Considerations
-
- This document requests that IANA establish a registry of zones which
- require this default behaviour. The initial contents of which are in
- Section 4. Implementors are encouraged to check this registry and
- adjust their implementations to reflect changes therein.
-
- This registry can be amended through "IETF Consensus" as per [RFC
- 2434].
-
- IANA should co-ordinate with the RIRs to ensure that, as DNSSEC is
- deployed in the reverse tree, delegations for these zones are made in
- the manner described in Section 7.
-
-
-7. Security Considerations
-
- During the initial deployment phase, particularly where [RFC 1918]
- addresses are in use, there may be some clients that unexpectedly
- receive a name error rather than a PTR record. This may cause some
- service disruption until their recursive name server(s) have been re-
- configured.
-
- As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
- namespaces, the zones listed above will need to be delegated as
- insecure delegations, or be within insecure zones. This will allow
- DNSSEC validation to succeed for queries in these spaces despite not
- being answered from the delegated servers.
-
- It is recommended that sites actively using these namespaces secure
- them using DNSSEC [RFC 4035] by publishing and using DNSSEC trust
- anchors. This will protect the clients from accidental import of
- unsigned responses from the Internet.
-
-
-8. Acknowledgements
-
- This work was supported by the US National Science Foundation
- (research grant SCI-0427144) and DNS-OARC.
-
-
-9. References
-
-9.1. Normative References
-
- [RFC 1034]
- Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- STD 13, RFC 1034, November 1987.
-
-
-
-Andrews Expires December 7, 2008 [Page 8]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- [RFC 1035]
- Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION", STD 13, RFC 1035, November 1987.
-
- [RFC 1918]
- Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
- and E. Lear, "Address Allocation for Private Internets",
- BCP 5, RFC 1918, February 1996.
-
- [RFC 2119]
- Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC 2136]
- Vixie, P., Thomson, A., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
- [RFC 2308]
- Andrews, M., "Negative Caching of DNS Queries (DNS
- NCACHE)", RFC 2398, March 1998.
-
- [RFC 2434]
- Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC 2606]
- Eastlake, D. and A. Panitz, "Reserved Top Level DNS
- Names", BCP 32, RFC 2606, June 1999.
-
- [RFC 3596]
- Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
- "DNS Extensions to Support IPv6", RFC 3596, October 2003.
-
- [RFC 4035]
- Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC 4159]
- Huston, G., "Deprecation of "ip6.int"", BCP 109, RFC 4159,
- August 2005.
-
- [RFC 4193]
- Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
- Addresses", RFC 4193, October 2005.
-
-
-
-
-Andrews Expires December 7, 2008 [Page 9]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- [RFC 4291]
- Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
-9.2. Informative References
-
- [AS112] "AS112 Project", <http://www.as112.net/>.
-
- [I-D.draft-ietf-dnsop-as112-ops]
- Abley, J. and W. Maton, "AS112 Nameserver Operations",
- draft-ietf-dnsop-as112-ops-00 (work in progress),
- February 2007.
-
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help]
- Abley, J. and W. Maton, "I'm Being Attacked by
- PRISONER.IANA.ORG!",
- draft-ietf-dnsop-as112-under-attack-help-help-00 (work in
- progress), February 2007.
-
- [RFC 3330]
- "Special-Use IPv4 Addresses", RFC 3330, September 2002.
-
-
-Appendix A. Change History [To Be Removed on Publication]
-
-A.1. draft-ietf-dnsop-default-local-zones-05.txt
-
- none, expiry prevention
-
-A.2. draft-ietf-dnsop-default-local-zones-04.txt
-
- Centrally Assigned Local addresses -> Non-Locally Assigned Local
- address
-
-A.3. draft-ietf-dnsop-default-local-zones-03.txt
-
- expanded section 4 descriptions
-
- Added references [RFC 2136], [RFC 3596],
- [I-D.draft-ietf-dnsop-as112-ops] and
- [I-D.draft-ietf-dnsop-as112-under-attack-help-help].
-
- Revised language.
-
-A.4. draft-ietf-dnsop-default-local-zones-02.txt
-
- RNAME now "nobody.invalid."
-
-
-
-
-Andrews Expires December 7, 2008 [Page 10]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
- Revised language.
-
-A.5. draft-ietf-dnsop-default-local-zones-01.txt
-
- Revised impact description.
-
- Updated to reflect change in IP6.INT status.
-
-A.6. draft-ietf-dnsop-default-local-zones-00.txt
-
- Adopted by DNSOP.
-
- "Author's Note" re-titled "Zones that are Out-Of-Scope"
-
- Add note that these zone are expected to seed the IANA registry.
-
- Title changed.
-
-A.7. draft-andrews-full-service-resolvers-03.txt
-
- Added "Proposed Status".
-
-A.8. draft-andrews-full-service-resolvers-02.txt
-
- Added 0.IN-ADDR.ARPA.
-
-
-Appendix B. Proposed Status [To Be Removed on Publication]
-
- This Internet-Draft is being submitted for eventual publication as an
- RFC with a proposed status of Best Current Practice.
-
-
-Author's Address
-
- Mark P. Andrews
- Internet Systems Consortium
- 950 Charter Street
- Redwood City, CA 94063
- US
-
- Email: Mark_Andrews@isc.org
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 11]
-\f
-Internet-Draft Locally-served DNS Zones June 2008
-
-
-Full Copyright Statement
-
- Copyright (C) The IETF Trust (2008).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-Andrews Expires December 7, 2008 [Page 12]
-\f
+++ /dev/null
-
-
-
-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]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server May 2005
-
-
- guideline for IPv6 host DNS configuration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong Expires November 6, 2005 [Page 2]
-\f
-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]
-\f
-Internet-Draft IPv6 Host Configuration of DNS Server May 2005
-
-
- Intellectual Property and Copyright Statements . . . . . . . . 33
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong Expires November 6, 2005 [Page 4]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+++ /dev/null
-
-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]
+++ /dev/null
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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
- \9fportable÷ 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]
-\f
-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]
-\f
-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]
-\f
-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 \9fN-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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 \9fcic÷ 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]
-\f
-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 \9fend user÷ ENUM, a
- domain tree different from e164.arpa should be used for \9fcarrier÷
- 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]
-\f
-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, \9fIntegrated 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-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]
-
-
+++ /dev/null
-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]
-
+++ /dev/null
-
-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
+++ /dev/null
-
-
-
- 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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
projects / thirdparty / bind9.git / commitdiff
